4.2 Schedule.

[Dirk Mueller]

On Wednesday 09 July 2008, Tom Albers wrote:

> So we are stuck to a large freeze period for ever?

What is the thing that you're most concerned about? that a long freeze period 
causes development to stall, or that it causes development to branch off in 
work-branches, private repositories, git trees etc?

Short freeze periods are fine if features are integrated with low regressions 
and well prepared. Not releasing or not defining milestones for 4 months 
however is something that I'm not feeling entirely comfortable with - not 
without compensating measurements being in place. Who tests for regressions 
whenever major changes have landed on trunk? How do we want to test for 
regressions if alpha releases don't get attention?

your suggestion reduces the freeze period from 8 weeks to 6. it however has 
the problem of overlapping with the 2 weeks of the year where, by past 
experience, most people are rightfully away. So in effect you're shortening it 
from 8 weeks to 4. you're also probably shortening feedback period from users, 
assuming that binary builds are not immediately available. Thats the part I'm 
not entirely comfortable with. 


Greetings,
Dirk