On Sat, Apr 21, 2012 at 10:17 AM, Sylvain Lebresne <sylv...@datastax.com> wrote: > +1 too. I also think it's a much more reasonable target. > > And I think that making our release schedule more reliable should be a > strong part of that change. For that, I wonder if having a more > organized QA period (basically a more codified release schedule) could > be beneficial. I won't hide that in my opinion our current > freeze-that-don't-freeze-much is not as much a useful tool than it > could be.
I always assumed this was a symptom of a release cycle that was too short. > For instance, I could imagine something like: > - 4 month dev > - 2 month before release: soft freeze, where we stop including "big" > issues and re-prioritize issues needed to get a consistent release. We > could also release the first beta like a week max after that. > - 3 weeks before release: hard freeze, where we really do focus on > fixing bugs only > - 2 weeks before release: first RC release. > > I'll precise that what we have so far has only be a soft freeze. I do > think that having a hard freeze would be beneficial to improve the > final release reliability and help towards releasing on time. > > Of course, all this is open to discussion. I'm not opposed, but I'd rather see us try a longer release cycle before introducing too much rigor here. Maybe a roadmap would be helpful. Again, I think it's worth avoiding too much rigor, but if we agreed on the largish items to be done during a cycle up front, with gates at various stages (phase 1 by date A, phase 2 by date B, etc), we might keep the scope from creeping as easily. -- Eric Evans Acunu | http://www.acunu.com | @acunu
