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
