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.
- [Qemu-devel] Improving patch tracking - something like ... Mark Cave-Ayland
-