Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <6005BE083BF501439A84DC3523BAC82DE204F16C05@LONPMAILBOX01.citrite.net>
References: 
 <6005BE083BF501439A84DC3523BAC82DE204F16A7E@LONPMAILBOX01.citrite.net>
	<5012AF05.6080609@widodh.nl>
	<CA+96GG4cdB=nuP03oqs1GLF_6Hh=Mk-MmSyb83BtyON7XJjQfg@mail.gmail.com>
	<6005BE083BF501439A84DC3523BAC82DE204F16C05@LONPMAILBOX01.citrite.net>
Date: Fri, 27 Jul 2012 16:37:11 -0400
Message-ID: 
 <CA+96GG4giBzGGhD5-T4iVjK=4GiY1MiKjACQsZZOgbSFa3XDrA@mail.gmail.com>
Subject: Re: CloudStack 4.0 release plan
From: Chip Childers <chip.childers@sungard.com>
To: cloudstack-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 27, 2012 at 1:33 PM, Ewan Mellor <Ewan.Mellor@eu.citrix.com> wr=
ote:
>> -----Original Message-----
>> From: Chip Childers [mailto:chip.childers@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 <wido@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, b=
ut it's taken much longer than anyone wanted to sort out the policy and leg=
al issues, and meanwhile there's tons of code being written by people and h=
eld 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 Ci=
trix 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 i=
t 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 a=
s we are legally able -- and to take whichever features are written and sta=
ble 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 r=
eady today.  Wido's RBD code went in yesterday, we've got a few more bits o=
f 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 c=
overs 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 release=
s or time-based ones (my preference is time-based, but I'm open to argument=
s 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