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.

Reply via email to