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.)
There's also something else to consider. Releases are like the heartbeat of a project. They stimulate activity, and they are pillars around which to market the project and spread the word. Hence, they bring new contributors to the project. We should be aiming to do as many of them as possible. In fact, frequency of releases is a reasonable proxy indicator for project health. Not that that there's much difference between 4 months and 6 months. (Now, 2 years might be a different matter...) But I'm just illustrating a point here. :) I think Joe hits the nail on the head when he points out that we haven't really given it enough time to know whether 4 months is working for us. I would suggest we give it give it a while longer, and then re-evaluate. On 24 April 2013 06:30, Alex Huang <alex.hu...@citrix.com> wrote: > I side with Dave and Chip on this one. The 4 month dev cycle has forced > CloudStack to own up to its problems in planning, testing, and automation. > Until that has been settled, going to a longer release cycle is actually > not beneficial to this community. > > --Alex > > > -----Original Message----- > > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] > > Sent: Tuesday, April 23, 2013 2:50 AM > > To: cloudstack-...@incubator.apache.org > > Subject: [DISCUSS] ACS Release 4 month v/s 6 month > > > > Folks > > > > We started discussing 4 month v/s 6 month release cycle in a another > thread > > [1]. Since the subject of that thread was different, community may not > have > > participated in this important discussion fully. I am are bringing this > > discussion to its own thread. Here is the summary so far please refer to > [1] > > for more details. > > > > Summary of discussion: > > - Animesh pointed out the technical debt that we have accumulated so far > > needs extra time to resolve > > - David, Chip favor shorter release cycle of 4 month and keeping master > > always stable and in good quality and enhancing automation as a solution > to > > reduce QA manual effort. A focused defect fixing activity may be needed > to > > reduce technical debt > > - Will brought up several points in the discussion: He called out heavy > > dependence on manual QA for a release and pointed out that manual QA > > may not be always available to match up ACS release schedule. Release > > overhead for 4 month release is still high and suggest that moving to 6 > month > > will save on release overhead and that time can be used for > strengthening > > automation. > > - Joe agrees partly in release overhead being significant for major > release > > > > If I missed out any important point please feel free to bring into the > thread. > > > > There were some other discussion in [1] on release planning conference > and > > chip's clarification on time based v/s feature based releases but we > will not > > discuss those in this thread. Community has agreed to time-based release > > already. > > > > [1] http://markmail.org/thread/6suq2fhltdvgvcxd > > -- NS
