Re: 8.5 development schedule - Mailing list pgsql-hackers

Bruce Momjian <bruce@momjian.us> writes:
> Kevin Grittner wrote:
>> However, even the *possibility* that this could be true is pretty
>> scary.  If we need to effectively shut down new development for seven
>> months at the end of a release, in addition to the interim commit
>> fests, we'd better get a handle on why, so that can change.  To what
>> do you attribute the extended time needed to handle the final CF?
>> How can that be made better?

> We had many patches that had been through previous commit-fests with
> minor adjustments and we had to finalize them before we could close the
> final commit-fest.  To be clear I am talking about patches that were
> eventually applied in 8.4, not patches that were rejected for 8.4.

I think this is simply not in agreement with the facts.  The patches
that caused the greatest amount of delay for 8.4 were the ones that
ultimately got rejected --- notably hot standby, sync rep, and
sepostgres.  Now the fact that everybody knew they would take awhile
provided some "cover" for other patches that weren't quite ready.
If we had bounced those three on Nov. 1 the commit fest would've been
a lot shorter.  Probably some other things that did get in would've
gotten bounced too, but on the whole I think the project would have been
better off.

The long and the short of it is that there is always tremendous pressure
to include patches that are on the edge of being ready, because we all
know that bouncing them to the next release cycle will mean an extra
year before they're available in production.  The dynamic in 8.4 was
exactly the same as it's been in the prior release cycles: we keep
slipping the possible release date and trying to get those patches
ready, and we don't give up until everyone agrees the release is just
hopelessly late.  As long as we keep behaving that way, no amount of
schedule-setting or rule-making is going to change anything.

It comes down to somebody having the willingness to say "no" and the
authority to make it stick.  Robert mentioned upthread that the
committers don't want to be seen as throwing their weight around,
which is quite true, but I have also noticed in the past that saying
"no" does not convince whoever is arguing that "this release will suck
if it doesn't have this feature".  And there's always somebody arguing
that side --- usually several people.
        regards, tom lane