Is it time for triage on the open patches? - Mailing list pgsql-hackers

From Tom Lane
Subject Is it time for triage on the open patches?
Date
Msg-id 4354.1331322451@sss.pgh.pa.us
Whole thread Raw
Responses Re: Is it time for triage on the open patches?  (Robert Haas <robertmhaas@gmail.com>)
Re: Is it time for triage on the open patches?  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Well, if you get to the point where you're done churning the code in
> the next week or so, I'm willing to do one or two more rounds of
> serious review, but if that doesn't get us there then I think we need
> to give up.  The energy you've put into this is commendable, but we're
> about to start the third month of this CommitFest, and until we get
> this release at least to beta or so, we can't start any new
> CommitFests or branch the tree.  That basically means that nothing
> else of mine is going to get committed until the current crop of
> patches are dealt with - or for a good while after, for that matter,
> but getting the current crop of patches dealt with is the first step.
> Of course, I also want to have a good release and I understand the
> necessity of spending time on other people's patches as well as my
> own, as I believe I've demonstrated, but I don't want to stay in that
> mode indefinitely, which I think is an understandable position.

This is a fair position, but I think it's a bit unfair to be applying
such pressure to just the command-triggers patch and not all the other
open issues.  Hence, $SUBJECT: is it time to start forcing this
commitfest to a conclusion, and if so what kind of schedule are we
trying to set?

Personally, the open patches that I'm excited about getting into the
tree (or at least trying hard to) are:* NULLs support in SP-GiST* Caching constant stable expressions per execution
and not that much else.  (I'm also interested in the pgsql_fdw patch
but I'm afraid that getting it to committable shape in the next week
or two may be unrealistic.)  Probably other people have their own,
different shortlists.

(This is not to say that I'm objecting to any other patches, only that
I'd push to delay closing the CF to finish these, but not others.)

I think a reasonable way to proceed might be to get some consensus on
a short list of patches we're willing to try to push to completion,
then set a schedule accordingly, and then anything that doesn't get
done by the deadline gets kicked to 9.3.

Or we can just keep drifting.  But the number of open patches that
are *not* Ready for Committer, nigh two months after the CF started,
is depressingly large.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [v9.2] sepgsql's DROP Permission checks
Next
From: Simon Riggs
Date:
Subject: Re: RFC: Making TRUNCATE more "MVCC-safe"