Let me attempt to summarize this thread, if I missed any glaring points feel free to bring them up
4 months: Proponents (9): Chip, Alex, David, Noah, Hugo, Joe, Sebastian, Prasanna, Rohit Reasoning: * We have not given proper shot to 4 month cycle, this was just the first time. Level of automation has increased between 4.0 to 4.1 which lays groundwork for better automation * Longer feature cycle will mean more features and bigger and more complex release * Faster feedback loop to respond and address problems and shorter wait time for feature delivery 6 months: Proponents (12): Will, Animesh, Edison, Frank, Min, Ilya, Kelven, Edison, Sudha, Radhika, Nitin, Mice Reasoning: * ACS currently has heavy reliance on manual testing and majority of QA comes from 1 company. Shorter release cycle puts more dependence on timely availability of QA to keep up to quality goals * ACS release is expected to be of good quality and support upgrades. Longer QA cycle will mean more soak time and better quality. * Less overhead on release fixed cost work (release notes, generating release artifacts) * Longer cycles also provides more flexibility in schedule for individuals in defect fixing I still see there is difference of opinion and not a clear consensus with 12 out of 21 ( approx. 60%) preferring 6 months. But going by the argument of not having given proper shot to 4 month cycle I will say we can keep 4.2 as a 4 month cycle and pull in all effort to make it successful. If it turns out that we can work with 4 month schedule that's well and good otherwise we can bring this topic again based on the results of running 4 month cycle. If there is no objection I will proceed with creating 4.2 release page, dashboards etc. on Monday Thanks Animesh > -----Original Message----- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: Thursday, April 25, 2013 9:24 AM > To: dev@cloudstack.apache.org > Subject: Re: [DISCUSS] ACS Release 4 month v/s 6 month > > On Wed, Apr 24, 2013 at 12:22:58PM +0100, Noah Slater wrote: > > I see where David is coming from. > > > > The longer you leave a release branch, the harder it becomes to QA, > > the harder it comes to test, and the harder it becomes to release. As > > has been mentioned already, you can think of this as a "release cost". > > More regular releases keep complexity down, and reduce anxiety over > > "will my feature make the next release?" (Only applicable in a > > time-based system, like we have it.) > > Indeed. And frankly the longer the "QA" cycle, the less interest the > community will have (seems to have) in resolving bugs from the pending > feature release. People move on, naturally, to the next feature they want to > work on. > > Frankly this is the reason that I feel like we are still waiting to ship > 4.1.0. > > -chip
