On Thu, May 30, 2013 at 01:52:28PM +0000, Sudha Ponnaganti wrote: > 4.2 already has lot of features ( Around 70+ features ) added and require > hardening once feature freeze happens. This release is bigger than any other > release. Even though 1 round of testing is being done for majority of the > features, there are quite a few that require community help to build quality. > By adding more features, it would be that much difficult to harden the > release. > > -----Original Message----- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: Thursday, May 30, 2013 6:13 AM > To: dev@cloudstack.apache.org > Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze > > 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. >
I have to say that I'm actually surprised at the number of developers that want to hold to the schedule... and I'm happy if we stick to our guns. I'm also OK with extending a bit (if that had been the consensus). Sounds like we are mostly agreeing that we should stick to the existing schedule for feature freeze? -chip
