Re: Commit fest queue - Mailing list pgsql-hackers

On Wed, 9 Apr 2008, Tom Lane wrote:

> Gregory Stark <stark@enterprisedb.com> writes:
>> What would move us in the direction of this mythical "patch tracker" would be
>> if we knew exactly what our workflow was. Once we know what our workflow is
>> then we could pick a tool which enforces that workflow.
>
> Well, I don't think we want or need an "enforced" workflow.  What we
> need is just a list of pending patches so that nothing falls through the
> cracks.

Making sure nothing falls through the cracks is exactly the point of an 
enforced workflow.  It might be a manual operation, it might be some piece 
of software, but ultimately you need a well-defined process where things 
move around but don't get dropped.  Exactly how said enforcement happens 
is certainly open to discussion though.

Last time I chimed in on this subject I tried unsuccessfully to move 
discussion into this area--trying to nail down the structure of a patch 
processing workflow--but all I managed to do was kick off was a discussion 
of the trivia involved with one step.  A better attempt is below.

> As you say, most of the work is in recognizing which emails deserve to 
> be entered into the list, and that's not subject to automation (not in 
> this decade anyway).

Sure, but that can still be an input to the workflow.

Since I'm unphased by criticism and have been watching this whole 'Fest 
fairly closely, I'll even throw out a sample for a more formal workflow 
outline.  Always easier to map this stuff out when you've got a dummy 
proposal to beat up.  This is aimed to look somewhat like what happened 
this time around (except using the newer tools that are basically built 
now) rather than to be a more grand vision:

Input:  submissions to -patches and -hackers
Processing:  Saved via mail reader software
Output:  mbox file with relevant items
Person:  Bruce

Input:  mbox file
Processing:  Run script
Output:  Patch queue detail wiki page, with links to the archives
Person:  Greg Stark via his script

Input:  Patch queue detail
Processing:  Manually editing page, perhaps with some tool assistance
Output:  Patch queue summary wiki page
Person:  Alvaro

Input:  Patch queue summary
Processing:  Patch committed, removed from page
Output:  Updated patch queue summary, e-mail to author
Person:  Tom, Bruce, other committers

Input:  Patch queue summary
Processing:  Patch changed to be a TODO item
Output:  Expanded TODO list, updated patch queue summary, e-mail to author
Person:  Bruce

Input:  Patch queue summary
Processing:  Patch rejected or bounced back with comments
Output:  Reduced patch queue summary, e-mail to author
Person:  Bruce

There's a clear hole for messages to fall into when they're being 
summarized into the patch summary step, I recall Tom saying something 
about items that didn't make it into the current summary.  That needs to 
be improved a bit.  I also note that I didn't diagram separate review 
steps because I didn't see them happen in a formal way this time around 
that I could use as a model.

As a sideline observer here it seems to me that Bruce has a good and hard 
to replace process to kick this all off already going, so don't mess with 
that.  It would be nice to find vict...err, volunteers to pull him out of 
the later steps though for a net reduction in his time.  Simply getting 
things organized better from the start should help with getting more 
people helping out with review; the common complaint seemed to be "I can't 
figure out what to help with in this big mess" which having a summary from 
the start should improve.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD