On Thu, Apr 07, 2011 at 07:21:26PM +0100, Daniel P. Berrange wrote: > On Thu, Apr 07, 2011 at 11:24:04AM -0400, Laine Stump wrote: > > Now that 0.9.0 is out, I'd like to ask everyone's opinions about > > patch review tools. [...] > > I'm sending this message 1) to see if others are feeling the > > pressure of the extra traffic too (or is my brain just processing > > more slowly :-/), Definitely, but I'm getting old maybe that's the reason :-) > > and 2) to learn what your opinions are of setting > > up such a system for libvirt (for *optional* use only), and any > > opinions you have on what's available (or maybe you could provide a > > recipe for how you already manage all the patches without going > > crazy). Why not ... > > Here's my list of requirements; feel free to add/shoot down: My own requirement is that it should not be intrusive, optional, and actually enhance productivity, not decrease it :-) [...] > > If I were going to investigate one of these and try setting it up, > > which do you think would have the greatest likelyhood of success > > (if any)? > > For me, any tool which requires visiting a web UI to submit or view > patch code review comments/feedback is a non-starter. All code review > feedback must be on the mailing list, and correctly threaded. > In other words, it would be a tool which serves a 'reporting' or > 'tracking' patch series, not a code review management system. agreed > AFAICT, patchwork is the only one expressly designed in this > manner. Their website sums it up nicely: > > "patchwork should supplement mailing lists, not replace them > > Patchwork isn't intended to replace a community mailing list; > that's why you can't comment on a patch in patchwork. If this > were the case, then there would be two forums of discussion > on patches, which fragments the patch review process. Developers > who don't use patchwork would get left out of the discussion." > > To also add to that, public mailing lists are a very good archival > system for code review / discussions. Once in a mailing list, you > can be pretty sure it'll never disappear from the web & is always > searchable from google. The same can't be said of most web apps. Very much agree. One of the key point of Open Source devel is that the design discussions, pros, cons and associated voices including dissenting ones are in the open and logged forever. Basically what would help me is something tracking git and the list and telling me "that has been applied", "that's an old version", "this need review" , "this was ACK'ed but never commited". I'm not sure patchwork really processes automatically, if I look at the qemu-devel example [1] I see only stuff in NEW, if you need manual intervention to set the status, it creates more work, so I hope there is something better. Whether it has a web UI or not is not necessarily important, a tracker which would post status to the list would be IMHO just fine (and possibly slight more efficient since I would be in the same context, and not having to go out of my mail to reach a browser). Daniel [1] http://patchwork.ozlabs.org/project/qemu-devel/list/?order=state&page=5 -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list