[llvm-commits] Dedicated commit lists

[Hal Finkel]

On Wed, 2012-02-08 at 16:13 -0600, David A. Greene wrote:
> "Sergei Larin" <slarin at codeaurora.org> writes:
> 
> >   Not that I do not like to read about every single commit going in to
> > the tree, but I would like to see if there is any support to
> > separation of llvm-commits into several project centric mailing lists
> > – something along the line of llvm-commits-rt, llvm-commits-polly,
> > llvm-commits etc. …?
> 
> I would find that very inconvenient.  I like the ability to see what's
> happening at a glance.
> 
> I'm not unsympathetic to your concerns about volume.  Perhaps we can
> adopt some kind of tagging system in the subjects so people can filter
> into separate folders if they want.
> 
> > I do see some “lost patches”/review requests being blamed on high
> > message volume, and deeply empathize…
> 
> This is an entirely different issue, I think.  I have always thought
> (and stated numerous times) that proposed patches should be sent to
> llvmdev.  It's the development list, after all.  They'll stand out and
> more eyes will be looking at them.  I don't think all that many people
> read -commits.

It might be worthwhile to have some kind of actual tracking system for
patches. I think this can be done without much overhead by using a
simple script that watches the mailing list. To be specific, how about
the following:

 - When submitting a patch, the e-mail must contain the keywords:
'PATCH: NEW'.

 - When the script sees replies to that e-mail it will assume that the
patch is being reviewed. It will warn (by sending a mail to the list) if
the mail stops (excluding from the original author) for some extended
period of time without some further state change.

 - The script will change the state recorded for a patch when it sees a
reply mail with the keywords, 'PATCH: REVISE' [the system is to wait for
a revised patch from the author], 'PATCH: APPLIED r[0-9]+' or 'PATCH:
REJECTED' or 'PATCH: WITHDRAWN'.

 - The script will maintain a database of some kind used by a simple web
app that can be used to view the current state of patches.

I think that using some system like this we can essentially keep the
current review protocol but also add some useful tracking so that things
don't slip through the cracks.

 -Hal

> 
>                                 -Dave
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory