David and Chip, To be clear about my proposal, I did not intend to propose that we push back the feature freeze by x days of time and subtract x days from testing. My intention is to add those days into the cycle without reducing the test window -- pushing the release date out x days.
Another perspective is that we are acknowledging the likelihood that 4.1.0 delay will cascade into the 4.2.0 cycle. Rather than hoping we can absorb the impact, we embrace it early to reduce the time pressure on the community, reset expectations with our users, and increase the probability of high quality release. Thanks, -John On May 30, 2013, at 9:39 AM, David Nalley <da...@gnsa.us> wrote: > On Thu, May 30, 2013 at 9:13 AM, Chip Childers > <chip.child...@sungard.com> wrote: >> On Thu, May 30, 2013 at 11:02:32AM +0000, Koushik Das wrote: >>> >>> >>>> -----Original Message----- >>>> From: David Nalley [mailto:da...@gnsa.us] >>>> Sent: Thursday, May 30, 2013 12:36 PM >>>> To: dev@cloudstack.apache.org >>>> Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze >>>> >>>> On Thu, May 30, 2013 at 3:02 AM, murali reddy >>>> <muralimmre...@gmail.com> wrote: >>>>> We should do a health-check of proposed features [1] which are at risk >>>>> for >>>>> 4.2 feature freeze before deciding to re-evaluate timelines. >>>>> >>>> >>>> We are supposedly doing time-based release, so we don't care about what >>>> features make it versus don't. >>> >>> 4.1 was also supposed to be a time based one but got delayed due to various >>> issues. So not sure what would be the right approach here. I think it makes >>> sense to look at the feature list to see if some of them (individual >>> features can be voted upon) can be accommodated in 4.2. If there are no >>> such features then there is no need for extending the cutoff date. >>> >> >> 4.1's *feature freeze* was not extended (with the exception of Javelin >> merging in at the very end). What delayed us were quality issues... >> and frankly the "stabilization" period isn't something that I personally >> consider to be the critical date to hit. It's going to vary, based on >> what we find during testing. To me, the time-based approach is focused >> on the feature merge window primarily, and (over time) getting some >> consistency in our actual release dates. I think we are still learning >> to work with a feature freeze... we can get better at the tail end >> after we get better at bringing in only *known good* features into >> master. > > Indeed. > Extending the feature freeze window only - means shortening the QA > window - which in practice either won't work, or denies reality. As we > get more robust automated QA we should be able to move the freeze date > later, and merge with greater confidence, but I don't see it at this > point. > > --David
