On Wed, 9 Apr 2008, Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
