On Wed, Aug 26, 2009 at 12:07 PM, Andrew Dunstan<andrew@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
