Re: postponing some large patches to 9.2

On Tue, Feb 8, 2011 at 2:02 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Mon, 2011-02-07 at 22:37 -0500, Robert Haas wrote:
>> - Range Types.  This is a large patch which was submitted for the
>> first time to the last CommitFest of the cycle, and the first version
>> that had no open TODO items was posted yesterday, three-quarters of
>> the way through that last CommitFest.  Some good review has been done.
>>  While more is probably needed, I think we should feel good about
>> what's been accomplished and mark this one Returned with Feedback.
>
> I submitted this clearly marked WIP, so I expected that it would likely
> be pushed to 9.2.
>
> However, I don't feel like I have the kind of feedback that will help me
> get it committed next commitfest. I did get some review, and that was
> helpful, but it was mostly on isolated details.
>
> The patch is a million little decisions: names, catalog structure,
> interface, representation, general usability, grammar, functionality,
> etc. Without some checkpoint, the chances that everyone agrees with all
> of these decisions at the beginning of the next commitfest is zero.
>
> Is the commitfest not the right place to do this? If not, then when?

That's a fair question, and I do understand the difficulty. I think a
CommitFest is the right place to do that. On the other hand, as I'm
sure you realize, I'm not keen to hold up 9.1beta for a feature that
isn't going to be committed until 9.2. In the 9.0 and 9.1 cycles, it
was my observation that patches which were submitted to the first or
second CommitFest got a lot of this kind of review and went onto be
committed without a problem, usually in the next CommitFest.
Absorbing patches at the end of the cycle is a lot harder, because
everyone who has been thinking about doing something for the release
wakes up and submits it, often half-finished, often at the very last
minute. Furthermore, it takes more time to review them even if they
ARE code-complete, because it takes more time to do a real
review-to-commit than it does to tell someone "call it a whisker
instead of a potato and delete all the comments about sweet potatoes".

I really don't think that getting this into 9.2 is going to be a
problem. Given the level of interest in this patch, there will be no
problem at all finding someone to do a detailed review when we're not
quite so pressed for time, and I'm willing to put some time into it
myself when I'm not quite so pressed for time. Although it doesn't
feel like it at the moment, we have actually made great strides in
absorbing large patches. We've already absorbed true seriailizability
and SE-Linux integration (cut down basic version) this release cycle,
and it looks like we're going to absorb extensions and hopefully
SQL/MED also. Those are all big, big pieces of work *by
non-committers*, and the fact that they've sailed in with hardly a
cross word is, to me, a very good sign for the future of our
development community.

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