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'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 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.
cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
