[Qemu-devel] Improving patch tracking - something like gerrit?

[Qemu-devel] Improving patch tracking - something like gerrit?

[Mark Cave-Ayland]

Hi all,

It should be fairly evident to most people that the volume of patches 
flowing through the qemu-devel mailing list is continually increasing, 
and it is becoming increasingly difficult to track which patches have 
been applied over time. This is particularly a problem where patchsets 
have dependencies on other patchsets which haven't yet been applied to 
git master, which can then cause merge conflicts due to length of time 
taken for the final series to be merged.

Is it time for QEMU to start looking at tools such as gerrit to help 
manage this process? There seems to be an increasing number of ping 
requests for outstanding patches (including my own) which don't get 
applied for weeks, and often even months because they target less 
popular platforms/subsystems and so don't always get the attention of 
the committers.

What I would like to see from such a tool would be something that would 
enable me to see which patches are being considered for each release, so 
that I can see if a particular patch I have submitted is being ignored, 
rejected or deferred to a future release.

Note that I think that one of the biggest benefits of such a tool would 
be during feature freeze, whereby the mailing list contains an avalanche 
of future and current PULL requests which have to be manually filtered 
by committers. This would help both developers and committers see what 
patches are definitely scheduled for the next release as opposed to 
patches being rejected at the last minute because the PULL request 
failed just before the release deadline.

Does anyone else have any thoughts/ideas as to how to better manage this 
process, particularly for a project like QEMU where the number of 
patches is considerably greater than the number of reviewers/committers?


ATB,

Mark.

Re: [Qemu-devel] Improving patch tracking - something like gerrit?

[Peter Maydell]

On 3 February 2014 12:45, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
> It should be fairly evident to most people that the volume of patches
> flowing through the qemu-devel mailing list is continually increasing, and
> it is becoming increasingly difficult to track which patches have been
> applied over time. This is particularly a problem where patchsets have
> dependencies on other patchsets which haven't yet been applied to git
> master, which can then cause merge conflicts due to length of time taken for
> the final series to be merged.
>
> Is it time for QEMU to start looking at tools such as gerrit to help manage
> this process? There seems to be an increasing number of ping requests for
> outstanding patches (including my own) which don't get applied for weeks,
> and often even months because they target less popular platforms/subsystems
> and so don't always get the attention of the committers.

So in general I would be happy to see better tooling for this
(currently I use a combination of gmail folders to track things
I ought to be reviewing or pulling plus Anthony's "patches" tool
to do the work of actually applying things).

The difficulty is coming up with one of:
 (a) a system that works even if some maintainers/submaintainers
     aren't using it
 (b) a system good enough that we can force everybody to use it

(Also (c) somebody needs to put in the work to set the system up
on some server, maintain it, explain how it works, etc.)

> What I would like to see from such a tool would be something that would
> enable me to see which patches are being considered for each release, so
> that I can see if a particular patch I have submitted is being ignored,
> rejected or deferred to a future release.

Typically I think submaintainers will reply to patches when they
apply them to trees. I suspect your actual problem is "there are
areas of the code base where patches do just get ignored because
of a lack of maintainers for them". You can generally tell the
difference between ignored/rejected/deferred with our current system:
it's whether there's a reply from somebody with negative review, or
saying 'ok but won't go in this release' or no email reply at all.

> Note that I think that one of the biggest benefits of such a tool would be
> during feature freeze, whereby the mailing list contains an avalanche of
> future and current PULL requests which have to be manually filtered by
> committers. This would help both developers and committers see what patches
> are definitely scheduled for the next release as opposed to patches being
> rejected at the last minute because the PULL request failed just before the
> release deadline.

Get pull requests (and patches for the release) in early, please.
The closer you get to the release deadline the more likely you are
to find that yes, some patches don't make it under the wire.

thanks
-- PMM

Re: [Qemu-devel] Improving patch tracking - something like gerrit?

[Daniel P. Berrange]

On Mon, Feb 03, 2014 at 12:45:31PM +0000, Mark Cave-Ayland wrote:
> Hi all,
> 
> It should be fairly evident to most people that the volume of
> patches flowing through the qemu-devel mailing list is continually
> increasing, and it is becoming increasingly difficult to track which
> patches have been applied over time. This is particularly a problem
> where patchsets have dependencies on other patchsets which haven't
> yet been applied to git master, which can then cause merge conflicts
> due to length of time taken for the final series to be merged.
> 
> Is it time for QEMU to start looking at tools such as gerrit to help
> manage this process? There seems to be an increasing number of ping
> requests for outstanding patches (including my own) which don't get
> applied for weeks, and often even months because they target less
> popular platforms/subsystems and so don't always get the attention
> of the committers.

Having had to use Gerrit for a long time on OpenStack, I'd never
willingly use it on a project I was in charge of for a number
of reasons

 - No practical integration with email based workflows for people
   who don't want to use web UIs to comment. You can download patches
   from tool using to view the code outside the UI, but to actually
   comment you need to use the RSI-inducing, pointy-clicky web UI.

 - Poor handling of patch series - it shows dependancies between
   patches but that is basically all it does, and even that has
   poor UI. People frequently review 1 single patch never noticing
   that its part of a patch series. There's no way to get a view of
   all patches in a series ordered correctly. If you tag them with
   a topic, you can view all patches in the topic, but it randomly
   re-orders the patches, making it basically useless.

 - Poor UI for browsing through historical comments on previous
   versions of the patch. The comments are split between multiple
   web page views so you again have pointy-clicky hell trying to
   read through historical comments.

 - Poor UI for browsing/querying pending patches. Reviewers typically
   find themselves having to write external/command line tools to
   query gerrit in order to workaround its limited UI.


So sure, gerrit can track every single patch submitted and tell you
if it is applied or not, but having used it, I can't say that it is
a net win overall, particularly if your development process is heavily
using large patch series.

Regards,
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 :|

Re: [Qemu-devel] Improving patch tracking - something like gerrit?

[Markus Armbruster]

"Daniel P. Berrange" <berrange@redhat.com> writes:

> On Mon, Feb 03, 2014 at 12:45:31PM +0000, Mark Cave-Ayland wrote:
>> Hi all,
>> 
>> It should be fairly evident to most people that the volume of
>> patches flowing through the qemu-devel mailing list is continually
>> increasing, and it is becoming increasingly difficult to track which
>> patches have been applied over time. This is particularly a problem
>> where patchsets have dependencies on other patchsets which haven't
>> yet been applied to git master, which can then cause merge conflicts
>> due to length of time taken for the final series to be merged.
>> 
>> Is it time for QEMU to start looking at tools such as gerrit to help
>> manage this process? There seems to be an increasing number of ping
>> requests for outstanding patches (including my own) which don't get
>> applied for weeks, and often even months because they target less
>> popular platforms/subsystems and so don't always get the attention
>> of the committers.
>
> Having had to use Gerrit for a long time on OpenStack, I'd never
> willingly use it on a project I was in charge of for a number
> of reasons
>
>  - No practical integration with email based workflows for people
>    who don't want to use web UIs to comment. You can download patches
>    from tool using to view the code outside the UI, but to actually
>    comment you need to use the RSI-inducing, pointy-clicky web UI.

"It's dead, Jim."

>  - Poor handling of patch series - it shows dependancies between

If the dead could get any deader, this one would now be.

>    patches but that is basically all it does, and even that has
>    poor UI. People frequently review 1 single patch never noticing
>    that its part of a patch series. There's no way to get a view of
>    all patches in a series ordered correctly. If you tag them with
>    a topic, you can view all patches in the topic, but it randomly
>    re-orders the patches, making it basically useless.
>
>  - Poor UI for browsing through historical comments on previous
>    versions of the patch. The comments are split between multiple
>    web page views so you again have pointy-clicky hell trying to
>    read through historical comments.

And deader again.

>  - Poor UI for browsing/querying pending patches. Reviewers typically
>    find themselves having to write external/command line tools to
>    query gerrit in order to workaround its limited UI.

*Boggle*

> So sure, gerrit can track every single patch submitted and tell you
> if it is applied or not, but having used it, I can't say that it is
> a net win overall, particularly if your development process is heavily
> using large patch series.

I think this system would reduce the time I spend on reviewing patches
sharply.  Sounds like a huge win to me!

Re: [Qemu-devel] Improving patch tracking - something like gerrit?

[Stefan Hajnoczi]

On Mon, Feb 03, 2014 at 12:45:31PM +0000, Mark Cave-Ayland wrote:
> Is it time for QEMU to start looking at tools such as gerrit to help
> manage this process?

This has been addressed by Daniel Berrange but I just wanted to add my
vote *against* gerrit.

Instead, look at tools that correlate mailing list emails with git
commits.  They complement the mailing list and don't force people to use
them.  The options that I'm aware of are Patchwork and Anthony's
"patches" tool.  Both have limitations and I haven't found them good
enough - but hopefully that can be fixed.

http://jk.ozlabs.org/projects/patchwork/
https://github.com/aliguori/patches

> There seems to be an increasing number of ping
> requests for outstanding patches (including my own) which don't get
> applied for weeks, and often even months because they target less
> popular platforms/subsystems and so don't always get the attention
> of the committers.

The answer isn't tooling, IMO.

Send "ping" emails but also be vocal when the development process isn't
working.  Point out specific cases where more maintainership bandwidth
is needed.

Then new maintainers can volunteer to fill in gaps.  Existing
maintainers can reflect on their performance and try to improve things
(I've been guilty of poor responsiveness many times myself).

Stefan