Re: Last gasp

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Last gasp
Date: 2012-04-06 07:22:34
Message-ID: 4F7E99BA.1080805@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shigeru HANADA 2012-04-06 10:39:36 Re: pgsql_fdw, FDW for PostgreSQL server
Previous Message Tom Lane 2012-04-06 07:19:55 Re: Last gasp