Re: Last gasp - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Last gasp
Date
Msg-id CA+TgmoaxNXibx-vWrsdGpFGJnMnCyYzNemf1kEPAhgQLir9_fg@mail.gmail.com
Whole thread Raw
In response to Re: Last gasp  (Peter Geoghegan <peter@2ndquadrant.com>)
List pgsql-hackers
On Tue, Apr 10, 2012 at 2:49 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> 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.

I think that's partly true and partly false.  I actually spend a lot
of time looking at patches that are not marked Ready for Committer, on
the theory that I'd like to move things along that haven't been
formally tagged with that designation if they are nevertheless ready
to go, whereas Tom I think actively avoids it, on the theory that no
one else will volunteer to review if the committers just do
everything.  These positions are in tension but neither seems to me to
be without merit.

I do understand that not everyone is going to write code that meets
our standards for commit, and I have rewritten my share of patches -
sometimes, even quite large patches - to try to bring them up to that
level.  I had more time to do that last year than I have this year,
because this year I've been focused on performance stuff.  But, on the
flip side, I think we still did a pretty good job handling pretty much
everything submitted before November.  The stuff that ran into trouble
was the stuff that came in at the end, which in many cases was not
only late to the table but overly ambitious in its scope.  I think the
question should be not so much "why didn't those big patches get
committed?" as "why does anyone think that they have a right to be
upset that they didn't?".  They were given, basically, two to three
extra months to become committable, and still fell short.  And I'm
still very willing to devote more time to them to make them
committable *even though they are not my projects*, but I am *not*
willing to do it while the features I worked hard on to get ready
early sit there and don't get released.  That might be a reasonable
expectation if the original patches were submitted in May and I had
blithely ignored them in favor of my own work all year, but that ain't
what happened.

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


pgsql-hackers by date:

Previous
From: Jan Urbański
Date:
Subject: Re: plpython triggers are broken for composite-type columns
Next
From: Magnus Hagander
Date:
Subject: Re: pg_receivexlog stops upon server restart