> -----Original Message----- > From: John Burwell [mailto:jburw...@basho.com] > Sent: Thursday, May 30, 2013 6:51 AM > To: dev@cloudstack.apache.org > Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze > > 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 > [Animesh>] Yes if we push out the freeze then the release date also gets pushed out by the same timeframe
> 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
