Re: Last gasp - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Last gasp
Date
Msg-id 4F7E99BA.1080805@2ndQuadrant.com
Whole thread Raw
In response to Re: Last gasp  (Daniel Farina <daniel@heroku.com>)
Responses Re: Last gasp  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 04/05/2012 05:03 PM, Daniel Farina wrote:
> To get to the point, I wonder if it makes sense for someone who has a
> better sense a-priori what they're looking for in a committable patch
> (i.e. a committer, or someone with a telepathic link to one or more)
> to delegate specific pieces of patches for thorough review, sketching
> some thoughts about pitfalls or hazards to look for.  Think of it as a
> patch checklist that is informed by the experience of a committer
> skimming its contents.

It's tricky to add this sort of idea into the current patch workflow in 
all cases.  A decent percentage of submissions bounce off a reviewer who 
doesn't commit, such that no committer spends time on them yet they 
still move forward.  Any idea that tries to involve committers earlier 
in the process risks using more of their time on things that ultimately 
are never going to pass toward commit anyway.  That is after all where 
this whole process started at, before CFs, and we know that didn't scale 
well.

We already have a loose bar in this exact area, one that suggests larger 
patches should first appear earlier in the development cycle.  That 
happened in this case, with a first submission in mid November, but it 
wasn't enough to make things go smoothly.

When I trace back how that played out, I think the gap in this case came 
from not being sure who was going to commit the result at the end.  If 
it's early January, and the community knows there's a large feature 
approaching because it's been around for over a month already, we better 
be asking who is going to commit it eventually already.  Many patch 
submitters agonize over "which committer is going to grill me most?", 
and the bigger the patch the more that impacts them.

Nailing that down and putting together the sort of early committer 
checklist you're describing strikes me as something that might happen in 
the first week of a CF, before there are normally a large pile of "Ready 
for Committer" things around.  Raising these question--who is 
interesting in committing big things and where they consider the bar to 
be--is something submitters who have a stake in seeing their patches go 
on might do.

It's better if people who are already working hard on features don't 
feel like they need to wander around begging for someone to pay 
attention to them though.  Ideally it would be the sort of thing a 
proper CF manager would highlight for them.  Unfortunately we often 
don't quite have one of those, instead just having people who sometimes 
make a bunch of noise at the beginning of a CF and then go AWOL. 
(cough)  No one is happy about that, and it's something that clearly 
needs to be solved better too.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Last gasp
Next
From: Shigeru HANADA
Date:
Subject: Re: pgsql_fdw, FDW for PostgreSQL server