Re: Last gasp - Mailing list pgsql-hackers

On Fri, Apr 6, 2012 at 8:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Smith <greg@2ndQuadrant.com> writes:
>> On 04/05/2012 04:27 PM, Simon Riggs wrote:
>>> It's shocking since after months of work and an especially extended
>>> edition CF, we expect people to deliver something, not just shunt the
>>> whole thing off as rejected with 1 days's notice to alter that
>>> outcome.
>
>> I don't think this is being fair to Robert.
>
> If we're going to ship a release at all, somebody's got to be willing
> to say "no".  Personally, been there, done that, got the t-shirt [1].
> Robert's just pointing out what has to be pointed out.

Just returned from a week away, so I'm chipping in on key points only.
I accept the command trigger patch is gone now and I would add
comments only about our processes.

The problem remains that we have wasted many months of development and
slipped a release on what appears to be an important, universally
popular feature that had bucket loads of early planning. We shouldn't
hide from recognising that as an issue.

I completely agree that somebody has to be willing to say No, since we
all agree that the default for any patch is non-acceptance.

My first observation is that if No is received early enough for
something to be done, then the outcome could be different. It was not
clear that this important patch was going to be totally refused and
many people have expressed their surprise about that. Noah signalled
to everybody that the FK locks patch was likely to be rejected and a
number of us have tried hard to save that, unluckily as it turns out.
So an early No helped people allocate their time on what they
considered to be important. In contrast the Command Triggers and FKs
for arrays patches received a No so late that nothing could be done.
So I fully agree that people should say No, but the key point is
*when* they say it. For the future, I think we should have a triage
week as the first week in each CF; lets shake out the No comments
early - in some cases nothing can be done and we can refocus attention
onto important topics.

Second, my point was that No should not be applied in black/white form
if at all possible. If some aspect of a patch is unworkable, it may be
possible to provide some of the functionality, rather than simply
nothing at all. That wasn't possible with FK locks, and maybe it was
possible with command triggers.

I do consider it the responsibility of a reviewer to salvage as much
as is easily and reasonably possible from each contribution. In most
cases that requires a few words from the reviewer, since many patch
contributors listen carefully to what is said and try hard to make
changes that work. Frequently I see reviewers simply making authors
dance around with various additions and tweaks; all very well if the
patch is acceptable, but its just a waste of time if there is no route
to acceptance laid out clearly by the reviewer. That's something I've
mentioned before: the reviewer *must* supply a list of things which,
if solved, would allow the patch to be accepted. Clearly there will
always be last minute issues that cause rejection.

If we can get our information transfer a little slicker we'd be able
to find more review time. Instead of spending months on their own dead
patches, people would be available to assist on those with a chance to
be saved. Our problem is not lack of resource, it is ineffective
delegation. As Hannu points out, he didn't know the patch would be
rejected, so he didn't know help was needed to save something useful.
I considered that the job of the CF manager, but perhaps it is was
not. In any case, it would seem best for the future if the CF manager
was not also a committer, since those people are clearly too busy to
do both roles as well as the project needs them to be. Just as our
processes evolved into the creation of CFs and a CF manager, we must
evolve again towards someone/team whose main task is ensuring that the
delegation problem is solved. That won't work by bossing people
around, it has to work by informing and encouraging people to
contribute in the ways that they wish.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services