> -----Original Message----- > From: libvir-list-bounces@xxxxxxxxxx [mailto:libvir-list-bounces@xxxxxxxxxx] On Behalf Of Daniel Veillard > Sent: Thursday, June 09, 2011 16:20 PM > To: libvir-list@xxxxxxxxxx > Subject: Availability of patchchecker > > As some may have noticed, I'm often behind on patch review and it > happens I notice patches way too late i.e. just before a release. > For some time I though that having something automatic to remind > me about unreviewed/unapplied patches would be a good way to fight > this. I know that Eric, Matthias, Dan ... scans mostly everything > but well are all getting quite busy and sometime things get forgotten > and that's bad for the person who spent time on it and it's bad for > the community. Asking to resend old patches tend to inflate the problem > it's not a solution and humanly it's poor taste. > > So I spent most part of the week writing patchchecker, it's an > automated tool, working out of the public mail archives and a git > checkout, and was tested only with libvirt but should work also with > other projects using MHonarc for mail archives and git (or could be > made more flexible, yadda yadda ...) > > http://www.libvirt.org/git/?p=patchchecker.git > git clone git://libvirt.org/patchchecker.git > > Check the README, there is an indexer to run regulary to extract from > the mail archives, and a command to try to show intereting things, > right now it reports only patches which didn't get any comments or > acks. It detects patchset but doesn't fully use them yet. It's crude > but it's automatic ! > > Next step is to so a bit of XML output and XSLT to export the output > as a web page on libvirt.org , I will also need to add support for > patch versioning i.e. being able to obsolete an older version with > a newer mail (or patch set). > > I guess discussion and patches should be held and sent to this list, > which already raises a limitation of this tool: it currently support > only one git checkout, and if you send a patch for it it will complain > if it doesn't get applied after being ACK'ed :-) > > BTW one of the results is that we should try to use the formal ACK > keyword all the time (capital) when accepting and commiting a patch and > I may occasionally send reply mail to threads with ACK or something > like COMMITED if the algorithm of the checker get stuck on one patch. > I really expect the amount of manual intervention to be limited to this > I want the tool to help me, not give me/us more work :-) > > Hopefully it may prove useful to a few of us, and possibly be > adapted to other projects (as usual I take patches :-) Just wondering - why not go with a tool more oriented at this like gerrit? -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list