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
rjsch...@suse.com
rschw...@ca.ibm.com
781-464-8147
