On 05/17/2012 05:29 PM, David Nalley wrote:
[lots of snippage below]
On Tue, May 15, 2012 at 9:59 AM, Robert Schweikert<rjsch...@suse.com> wrote:
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.
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.
I agree, and personally feel very strongly that we should be targeting
a time-based release. I don't know if I like the 6 month cycle - 3 or
4 given the rate of innovation in the field seems a little more
manageable. At the same time, maybe X.Y (as defined below) is what
happens on those release cycles and we permit X.Y.Z+1 more
frequently but constrained to bug fix only releases.
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.
This is exactly why I feel strongly about time-based releases. And
even in time-based releases there can be slips, but nothing near the
level that we see with feature-based releases. This positively sets
the expectations among users around when to expect something new, it
affirmatively sets the schedule/plan with contributors, so everyone
can know exactly what is going on and when, how much time they have
left to work on issues, etc.
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)
Wholeheartedly agree with the above versioning logic.
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.
What do we think is a reasonable time to get a release out? 3 months?
4 months? 6 months? Lets find where we need to place the stake and do
so soon.
I think some scoping needs to be done before the stake is placed. Take
the dependency list as an example:
- what does it take to get xenserver-java bindings into the wild?
- how hard is it to remove iHarder.net - base64 from being used
and there are a few more. The goal should be that all depended code
falls under one of the SPDX listed [1] licenses, preferably an OSI
approved license. Anything else will just cause trouble with distros
picking things up. Therefore the comment in the list [2] "receive
approved license" does not really work (the way I interpret the meaning
of this statement). Each of these dependencies must have an upstream
project such that distros can pick up the source and build packages.
Everything else will cause trouble.
I have no idea how difficult this will be, but from my point of view
this will be the long pole.
It looks like that the admin pieces are falling into place. My guess is
that it takes probably 4 month to sort out most if not all the
administrative stuff, get Jira set up. Migrate the source to the Apache
infrastructure etc. But in the end I would say that "fixing" the
dependencies will be the longer and more difficult task.
Later,
Robert
[1] http://spdx.org/licenses/
[2]
http://wiki.cloudstack.org/display/dev/Moving+dependencies+to+ASF+approved+licenses
--
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
