[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Improving patch tracking - something like gerrit?
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] Improving patch tracking - something like gerrit? |
Date: |
Mon, 3 Feb 2014 13:30:11 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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 :|