damage control mode

On Thu, Jan 7, 2010 at 4:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Jan 7, 2010 at 3:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>> I am tempted to say we should clamp down and go into damage control
>>>> mode sooner rather than later.
>>>
>>> The more I see of the HS patch, the more I think the same.  But my
>>> proposal for "damage control mode" would be to immediately punt
>>> everything else to the next release and focus our energies exclusively
>>> on HS *and* SR.
>
>> Hmm.  There's something to what you say, but what about the people who
>> were expecting their patches to be reviewed and perhaps committed in
>> the forthcoming CommitFest.  I proposed a schedule for this release
>> that involved only three CommitFests and it was rejected, so it seems
>> a bit unfair to pull the rug out from under people at the eleventh
>> hour.  Will we lose developers if we do this?
>
> Well, I think we should put at least some effort into clearing out
> the underbrush.  There's a lot of pretty small stuff in the January CF
> list that I think we could go through in a short time.  The biggies,
> IMO, are the ones you noted:
>
>> Unfortunately, there are some patches that I probably will not feel
>> confident to commit without your input - in particular, writeable
>> CTEs, listen/notify, more frame options in window functions -
>
> and Teodor's GIN/GIST stuff.  If we feel that we are in schedule
> trouble I think that bumping these to the next release is by far
> the sanest response.  Bumping SR so we can get these in would be
> completely misguided.

OK, we have a proposal on the table to bump some patches from this
CommitFest to free up more committer resources, particularly Tom, to
work on Hot Standby and Streaming Replication and attempt to
accelerate the process of getting 8.5 out the door. This proposal
needs input from the community. The affected patches are:

- Listen/Notify Rewrite.
- Writeable CTEs.
- more frame options for window functions
- knngist
- rbtree

Tom wasn't specific about which of the GIN/GIST patches he was
discussing, but I'm excluding point_ops from this list because I have
already reviewed it and believe that it requires only trivial changes
prior to commit.

I believe that it is certainly fair to bump the last three of these
patches, because they are all large patches which have been submitted
for the first time at the end of the development cycle. I previously
suggested a rule of thumb that any patch which, when considered as a
unified diff, had a total number of lines added and lines removed >
1000, would not be considered for the last CommitFest unless it had
been submitted to the second-to-last CommitFest. That rule would
apply to all three of these patches (though rbtree only just barely)
and I think it makes sense to go ahead and apply it, postponing all of
these to 8.6.

The decision to preemptively bump listen/notify rewrite or writeable
CTEs would be somewhat more painful to me because I do feel that the
patch authors have basically followed the rules - both have been
submitted and reviewed previously and are resubmitted here with
improvements coming out of those prior reviews. On the other hand, we
don't have infinite resources, and Streaming Replication is a
big-ticket feature whose patch author has ALSO followed the rules - in
fact, even moreso - I don't believe it's received a full review since
being submitted, after a substantial rewrite, to the SEPTEMBER
CommitFest. So I could go either way on this one.

It should be noted that the decision to bump these patches does not
guarantee that SR will be part of 8.5, though it should improve our
chances. It also does not guarantee that the release will happen "on
time", though it will presumably help with that, too.

Votes?

...Robert