Andrew Dunstan <and...@dunslane.net> wrote: > 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. Unless the community can reduce the time between the start of the last commit-fest and the release, you're limited to an average of four months of programming time per year for new features (assuming that people are observing the rules about what they should be doing during commit-fests and beta testing). If you want to move the next release back into Spring rather than Summer (which is the season in which 8.4 was released -- at least of those of us in the Northern Hemisphere), you would need to shorten that to three months for this release. Unless... Both the ruthless cutting of anything not totally ready at the end of a commit-fest, *and* reducing the time from the end of the last commit-fest to release would be needed to get that up to five months per year. We obviously don't want less testing during the beta cycle, but delaying the release while the release notes are developed at the end of the cycle seems like an obvious target for improvement. I'd bet there are others, though I don't know what they are.... -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers