On Wed, 2009-01-28 at 14:55 +0100, Magnus Hagander wrote: > If the release is pushed back, maybe some other patch could also have > been finished by the new deadline - should that also be included? What > about a completely new feature that isn't even started yet, but that > could easily be finished before the new deadline? What makes those less > worthy?
Committers have always added features after freeze... For example, Virtual TransactionIds were added to 8.3 almost exactly 5 months after feature freeze. Not even suggested until about 5 months after, in fact. I argued against such a change late in the cycle, but we did it. It's a great feature and I'm glad we did. If we try to shorten the release cycle, we just end up missing out on tuning opportunities that emerge in beta. IIRC 8.2 was delayed while we changed index cost models. Thankfully. 8.0 was shipped with a completely ineffective bgwriter, so the above changes seem like common sense in comparison. The only way to keep the dev window open longer is to overlap the start of the next cycle with the previous one. i.e. branch new version before final release. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
