On Fri, Jul 27, 2012 at 1:33 PM, Ewan Mellor <ewan.mel...@eu.citrix.com> wrote: >> -----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.
Can the community help with the policy issues that you are talking about? I know some of us are working through licensing issues, but I'm not sure what else you might be referring to (are these all on the wiki page for license issues?). I wasn't suggesting that new features not be added. Obviously Citrix (and others like Wido, etc...) are working on new features, based on their personal or organizational priorities. Don't stop! I was just pointing out that we had agreed that ASF licensing / legal issues were the priority for 4.0. If there is an in-progress feature that isn't completed by the time we are ready legally, then I was assuming that it doesn't ship with 4.0. > 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. +1 - We're in agreement then! > 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. To David's point, we agreed on time-based releases (once we get to 4.0). -chip
