cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: Summary of IRC meeting in #cloudstack-meeting, Wed Jan 30 17:04:52 2013
Date Thu, 31 Jan 2013 20:52:00 GMT


> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Wednesday, January 30, 2013 2:40 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Summary of IRC meeting in #cloudstack-meeting, Wed Jan 30
> 17:04:52 2013
> 
> > That being said, the question of "what happens if a feature doesn't
> > make it in time for the current release schedule's feature freeze?" is
> > actually more appropriately asked of the community as a whole.  I did
> > propose a feature freeze for Jan 31.  If that's not the community
> > consensus, then we can certainly change it with consensus around a
> > different plan / schedule.
> >
> > With my individual contributor hat on, I feel like a hard feature
> > freeze is a good thing.  We should stick with it.  There will be more
> > releases after this one, and the better we get at following a
> > time-based schedule the easier and more predictable it will be for
> > ourselves and our users.  I personally don't think that anyone should
> > feel "rushed" to get something into a particular release.  It's better
> > to get things done *right*.
> >
> 
> 
> So generally speaking - slipping the schedule for a feature inclusion
> is a completely different release strategy (feature-based releases).
> IMO we discussed this at length and the benefits of a time-based
> release far outweigh any short term gain for feature inclusion.
> Generally speaking, my personal opinion is that features aren't worth
> slipping the schedule. I expect we'll have enough issues that cause us
> to slip that we won't need features to add to it.
> 
> Hard freeze is a good thing. Our release cycles are short for a
> reason, so that even if you miss a release, the next one isn't too far
> off, and far better to have a well developed and tested release with
> fewer features than a more hastily assembled that is potentially more
> broken.

+ 1 on that.  We said time based then it should just be time based.  It's hard to start with
but will help everyone learn the discipline.  

My only problem is with review boards.  If the contributor already submitted patches in time
then it's up the community to help get that in, even if it's passed the deadline.

--Alex

Mime
View raw message