incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Schweikert <rjsch...@suse.com>
Subject Re: [DISCUSS] releases going forward
Date Tue, 15 May 2012 13:59:35 GMT
Hi,

On 05/14/2012 03:06 PM, David Nalley wrote:
[snip]

> The concern is that there is a fairly significant amount of work to be
> done to generate an Apache CloudStack release - a good deal of which
> will be trial and error and completely new processes. By way of
> reference - it appears that Apache OpenOffice took about 10 months
> from entering incubation to pushing out a release. I think we are
> substantially better off with less to migrate than AOO - but
> nonetheless it could be a non-trivial amount of time, whereas we have
> historically been doing about a release a month.

A release a month does not work for packagers. With CloudStack code 
being open source it can be included in distributions. If there is a 
release every month packagers will quickly feel like they are chasing 
their own tail and thus give up. Other cloud platforms appear to sustain 
their momentum with a timed release cycle of a bout 6 month. This is a 
reasonable time period for packagers of a comunity distribution.

>
> At the same time, pushing out a Citrix-generated CloudStack release is
> a pretty closed process - QA happens behind closed doors, as does
> decision making about dates, release criteria, and virtually
> everything else. It also requires a non-trivial amount of work for
> folks who presumably would be otherwise engaged in pushing Apache
> CloudStack forward.
>
> While I certainly hope that 10 (or even 6)  months doesn't go by
> without a release, my personal inclination is to focus on Apache
> CloudStack - but I am but one voice - please discuss.

I think one needs to think about the long term goal first. for this 
there are only two models, either feature based releases (release date 
floats) or time based releases (no "guaranteed" features). Many projects 
do well with time based releases. With a release cycle of 6 month it is 
not really that tragic if a particular feature misses a given release as 
it will be in the next release (if it's ready) that is only 6 month away.

The key to time based releases is to hit he "promised" date. Time based 
releases where the date slips all the time are not in fact time based 
and people loose interest as the project is seen as unreliable.

Citrix can choose to have releases of their platform whenever they want 
and can pull code from the repo as and when they see fit. This should 
not influence the release cycle of the community.

My suggestion would be to go with a 6 month time based release cycle and 
also decide on a version numbering scheme.

X.Y.Z

- X : increases when there is a "major" change in architecture or some 
major new feature
- Y : increases with every release every 6 month (reset when X increases)
- Z : increases when there are "must fix bugs" or annoying bugs that get 
fixed in a release branch (reset when Y increases)

I think it would be reasonable to make a list of what needs to be done 
to get a community release out the door and then put a stake in the 
ground and say "we will be done on XXXXX". Count this as the first 
release and then switch to the time based model. What Citrix does in 
between is should not really have an effect. Of course it will on timing 
as initially there is probably a lot of work required by Citris 
contributors to get processes, testing etc. moved toward the community.


My $0.02
Robert


-- 
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead
rjschwei@suse.com
rschweik@ca.ibm.com
781-464-8147

Mime
View raw message