On Wed, Aug 26, 2009 at 12:07 PM, Andrew Dunstan<and...@dunslane.net> wrote: > Robert Haas wrote: >> >> I am assuming that at least Hot Standby and Streaming Replication will >> likely require two CommitFests to go from the point where they are >> seriously reviewable to actual commit. So if they hit the 9/15 date, >> they should make 8.5 even with just three CommitFests. If they don't >> hit the 9/15 date, then a 3-CommitFest cycle will probably be too >> short for them to make it in. But if we schedule a fourth CommitFest >> in January in the hopes of seeing one of those patches committed, then >> ISTM we're basically speculating that the patch authors will not hit >> the 9/15 date but that they will hit an 11/15 date. > > My concern is not just with those features, but with the whole ratio of the > window for new work to the total development cycle. That ratio keeps going > down and the time the tree is effectively frozen to new features keeps going > up.
I think that's a very valid concern. Against that, if release cycles become very long, then features can hit the tree more of the time, but they don't get into a released version for ages. > I'd like to see us keep the tree open as long as possible but be much > more ruthless about chopping off things that aren't ready at the end. That > way we can quickly get to a beta and get on with the next cycle I'm happy to assist with that, but recall that even after we ended CF 2008-11 another four months went by before release. That's a whole lotta time for the tree to be closed right there. > I realise > the idea is that significant features must be submitted by the penultimate > CF, but I'm not too sure how well that's going to work in practice. That > just seems like we're relabelling things rather than a fundamental change. > At the very least my vote goes for four CFs rather than three. Fair enough, more votes are good. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers