[libvirt] Availability of patchchecker

[Itamar Heim]

> -----Original Message-----
> From: libvir-list-bounces at redhat.com
[mailto:libvir-list-bounces at redhat.com] On Behalf Of Daniel Veillard
> Sent: Thursday, June 09, 2011 16:20 PM
> To: libvir-list at redhat.com
> Subject: [libvirt] 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?