Re: Last gasp - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Last gasp
Date
Msg-id CAEYLb_XEBrR6yUpKBfbRKEE8iXA0T0zKT-8nOteKpMGOrsAZ5A@mail.gmail.com
Whole thread Raw
In response to Re: Last gasp  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Last gasp  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Last gasp  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 10 April 2012 18:28, Robert Haas <robertmhaas@gmail.com> wrote:
> If we accept your argument that some
> people simply cannot help themselves, then the only solution is to
> make it cease to be a prisoner's dilemma, and that can only be done by
> changing the incentives, which presumably means handing down
> punishments to people who push their own patches forward at the
> expense of others.  Unless we care to choose a benevolent dictator, I
> don't see any way to accomplish that.

Well, I was really pointing out that people are somewhat forced into a
corner by the current state of affairs, because committers are not
typically able to look at anything in sufficient detail that isn't
"ready for committer", particularly as we approach crunch-time - their
time is simply too precious. By not marking the patch ready for
committer, they are basically asking for their patch to be passed
over, and they may be incapable of bridging the chasm between what
really is their best effort, and what'd you'd consider to be the
ready-for-committer gold standard. Some people cannot exclusively
dedicate their time to their patch, or lack sufficient experience to
meet that standard.

> It's feasible to think that we might be able to streamline the process
> of booting patches that are not close to committable at the start of a
> CommitFest, and especially at the start of the final CommitFest.  For
> example, limiting patches to a small number of days in the "Waiting on
> Author" state would help a great deal.  But the more general problem
> of people arguing that *their* patch is the special one without which
> the earth will cease to revolve about its axis is more difficult to
> solve, or that it's ready when it's really not, is more difficult to
> solve.  How would you propose we deal with that problem?

As I've already said, I think that needs to be decided impartially,
ideally by people who are removed from the engineering process. I
don't mean that we'd get a marketing person to make those decisions -
far from it. I just mean that some separation of powers can be a good
thing in some circumstances.

> I don't agree with that.  I think that there are a few people who
> don't now have commit bits who should be given them - in particular,
> Fujii Masao and Kevin Grittner, both of whom have been doing
> consistently excellent work for several years.

I agree with you about both individuals. I hope that this happens
sooner rather than later.

> Giving more people the ability to
> commit stuff will neither force them to devote time to it nor make
> them qualified to do it if they aren't already.

One major component of being qualified, is, of course, knowing what
you don't know, and the risk of being left with egg on your face turns
out to be a pretty effective way of preventing new committers from
being too eager. Giving more people bits has a cost: in general, I'd
expect it to result in a higher bug-to-line ratio when code is
committed. However, not doing so has an opportunity cost: less code is
committed, which may, on balance, result in an inferior release than
what we could have had. Maybe you think that we have the balance
perfectly right, and you are of course perfectly entitled to that
view, as well as being perfectly entitled to having your opinion more
heavily weighed than mine, but I'd like to see a dialogue about it at
some point.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: plpython triggers are broken for composite-type columns
Next
From: Tom Lane
Date:
Subject: Re: Last gasp