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

[Peter Maydell]

On 3 February 2014 12:45, Mark Cave-Ayland
<address@hidden> 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