cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sudha Ponnaganti <sudha.ponnaga...@citrix.com>
Subject RE: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Date Thu, 30 May 2013 13:52:28 GMT
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.childers@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:david@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 
> > <muralimmreddy@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.

Mime
View raw message