qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mark Cave-Ayland
Subject: [Qemu-devel] Improving patch tracking - something like gerrit?
Date: Mon, 03 Feb 2014 12:45:31 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]