> -----Original Message----- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: 27 July 2012 08:14 > To: cloudstack-dev@incubator.apache.org > Subject: Re: CloudStack 4.0 release plan > > On Fri, Jul 27, 2012 at 11:08 AM, Wido den Hollander <w...@widodh.nl> > wrote: > > How are we going to decide what is going into 4.0 and not? > > > > Do we have a list of functionality what we want to see in 4.0? > > > > Wido > > If memory serves me, I thought the list previously agreed that 4.0 > would focus on meeting the licensing, IP, etc... requirements for ASF. > I think that the new features are fantastic, but I'd prefer if we > remained very focused on getting to an official ASF release done > first. > > This does beg the question though: how do we want to proceed with > future release planning and execution?
Hi Chip, Yes, we are focussing on getting the licensing and IP issues addressed, but it's taken much longer than anyone wanted to sort out the policy and legal issues, and meanwhile there's tons of code being written by people and held in feature branches. The policy issues have become the long pole. What I really don't want is for Apache 4.0 to have fewer features than Citrix 3.0.x. That would just be broken. But we have a whole team of people who are still writing code, and they don't have anywhere official to put it while these policy issues get sorted out. My proposal is to have the 4.0 release be time-based -- we ship as soon as we are legally able -- and to take whichever features are written and stable at that point. We're nearly ready to go (my proposal was only two more weeks of feature development before we go into stability-and-bugfixing) so that would mean that the feature set is whatever code is ready or nearly ready today. Wido's RBD code went in yesterday, we've got a few more bits of refactoring to do for policy reasons, and there's Alena's VPC branch and the autoscale branch almost ready for review. If we want to ship our first official release as soon as it is ready (and I do) then that pretty much covers it in terms of features. In terms of future planning, that's a conversation I was hoping to start next week. We need to decide on whether we're doing feature-driven releases or time-based ones (my preference is time-based, but I'm open to arguments about that) and then we need to decide on a release cadence, a mechanism for feature proposal and review, and whether we're going to have long-term stable branches and if so who would be prepared to maintain them. Cheers, Ewan.
