Re: Last gasp - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Last gasp
Date
Msg-id CA+TgmoYqPXFRQzDWDSka8hgX1TqbMvKit2zYDZ9cw0x81Uj52g@mail.gmail.com
Whole thread Raw
In response to Re: Last gasp  (Greg Smith <greg@2ndQuadrant.com>)
Responses Re: Last gasp  (Greg Smith <greg@2ndQuadrant.com>)
List pgsql-hackers
On Tue, Apr 10, 2012 at 8:43 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> The main reason I worry about this is because of a very real chicken/egg
> problem here that I keep banging into.  Since the commit standards for so
> many other open-source projects are low, there are a non trivial number of
> business people who assume "!committer == ![trusted|competent]".  That makes
> having such a limited number of people who can commit both a PR issue ("this
> project must not be very important if there are only 19 committers") and one
> limiting sponsorship ("I'm not going to pay someone to work on this feature
> who's been working on it for years but isn't even a committer").

I'm not sure what the best way to address this problem is, but I don't
think it's to make more people committers if they aren't truly
qualified.  If someone's work is going to require substantial
revision, it is much better and much less work to do that revision
before the code goes into our repository (and particularly, before it
gets released) rather than after.  And, on a related note, I am having
a hard time imagining that it's a good idea to give very many people
commit bits primarily so that they can commit their own work.  We
could create quite a few such committers and not really solve whatever
bottleneck exists here.  What we really need are committers who are
willing and able to spend the time to do high-quality reviews of other
people's work.

I find this whole line of thinking particularly troubling in view of
Peter's comments that contributors face a prisoner's dilemma situation
and will inevitably push their own patches forward at the expense of
other people's patches.  That behavior is only a mild nuisance when
people without a commit bit do it, but it's potentially a lot more
disruptive if someone who has a commit bit does it, because the
default for whether the patch gets committed flips from no to yes.  I
think our committers need to be people we can trust enough NOT to
engage in such behavior.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Different gettext domain needed for error context
Next
From: Robert Haas
Date:
Subject: Re: Patch: add timing of buffer I/O requests