openstack team mailing list archive

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Fri, Jun 29, 2012 at 03:27:25PM -0500, Andrew Bogott wrote:
> On 6/27/12 8:40 AM, Daniel P. Berrange wrote:
> >On Wed, Jun 27, 2012 at 03:24:21PM +0200, Vincent Untz wrote:
> >>Hi,
> >>
> >>
> >>It'd be really great if we could first improve Gerrit to handle the
> >>patch series workflow in a better way. Without such a change, pushing
> >>patch series to Gerrit is really no fun for anyone :/
> >>
> >>
> >Yep, no argument that Gerrit could do with some improvements, but having
> >submitted a number of non-trivial patch series to Nova, I don't think
> >current Gerrit UI is a complete blocker to adoption. It is not ideal,
> >but it isn't too painful if you're aware of what to look for. I think
> >the main problem is that since the patch dependancies are not obvious
> >in the UI, reviewers tend to miss the fact that they're reviewing a
> >patch that's part of a series.
> >
> I agree that patchsets are better than monolithic patches.  Today,
> though, I am working on a 3-patch set and the process is driving me
> crazy.
> 
> a)  Any time Jenkins has a hiccup, I have to resubmit the entire
> patchset.  This obscures any reviews or votes that might be attached
> to other patches in the set.

Yeah, this is a major PITA. We need an easy way for patch authors
to retrigger Jenkins without re-submitting each time.

> b) Similarly, any time I change a single patch in the set, I have to
> resubmit the whole set, which causes review history to be obscured,
> even for those patches which have not changed at all.

Gerrit will look at the GIT changeset hashes and notice if only
2 out of the 5 patches have actually changed. THe trouble is that
'git review' with no args will always rebase your patch series
against master before pushing. So even if you only modified the
last patch in your series, this will make Gerrit see all the patches
as new :-(

I'm getting into the habit of always running 'git review --no-rebase'
to get around this behaviour.

> Case b) would be entirely solved via a fix to  this:
> http://code.google.com/p/gerrit/issues/detail?id=71.  That would
> also help with a) but not resolve it entirely... the best solution
> to a) would be a 'retrigger' button in Jenkins or a 'prompt Jenkins
> to re-review' button in Gerrit.  The fact that people (including me)
> are submitting trivial edits to patches only in order to nudge
> Jenkins is pretty stupid.

I must say that this has been driving me mad this last week. IIUC, only
members of the core review team have permission to retrigger Jenkins,
but I feel it is putting too much burden on them to have to track every
patch with a bogus Jenkins failure. If we can't get Jenkins to be more
reliable, then can we see about letting patch submitters retrigger
Jenkins builds for their own patches.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|