[libvirt] Availability of patchchecker

[Daniel P. Berrange]

On Sun, Jun 19, 2011 at 05:15:55AM -0400, Itamar Heim wrote:
> 
> 
> > -----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?

Code review of patches can often lead off into tangential technical
discussion and we want this all to take place on the mailing list.
Requiring every mailing list subscriber to also monitor a web based
tool will also reduce contributions from the community, and splinter
technical discussions. So putting any web based tool like gerrit into
the development workflow is a non-starter.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|