Marcus, I think it best to defer the larger release cycle length question to another time and place. As Chip stated earlier, the consensus is to maintain the current freeze date. Given the time sensitivity, my proposal can be considered resolved.
Thanks, -John On May 30, 2013, at 11:34 AM, Marcus Sorensen <shadow...@gmail.com> wrote: > I think there does need to be some course correction, but perhaps we > should look at the development cycle overall and the lessons learned > from 4.1. Did we not allocate enough time for bugfixing? Did we allow > too many low-quality merges for the time allotted? Did we have issues > with the overlap (allowing new features into master while bugfixing/QA > needed to be focused on)? Or something else? Or maybe all of it? > > One thing that may help is to have some sort of feature review during > the development cycle. Maybe at the halfway point we make a list if > what will be in this release, with the intent of weeding out last > minute bombs being dropped just before feature freeze. If a relatively > large change isn't feature complete and its devs don't have it testing > 3-4 weeks before feature freeze, then it gets moved to the next > release. Sort of a sliding window for feature freeze, based on > complexity. I know we've sort of said 'big changes can only land at > the beginning of a cycle' once or twice, but I think making it > official via some sort of review that pins features into releases > would be helpful in solidifying that (as well as developer > expectations). > > Or maybe we extend the time between feature freeze and code freeze, > knowing that features are inevitably going to be rushed in at the last > minute. > > I'm not sure what the correct answer is, but if we're going to talk > about adjusting the 4.2 release, I thought it might be wise to > consider fine-tuning the development cycle in general. > > On Thu, May 30, 2013 at 8:56 AM, Chip Childers > <chip.child...@sungard.com> wrote: >> 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
