cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hugo Trippaers <>
Subject RE: [ACS41] 4.1 branch created
Date Sun, 03 Feb 2013 07:03:38 GMT
Heya all,

I find it way too early to cut a 4.1 release branch. I now that this is what we agreed to
do, but the way we are going at it doesn't sit right with me. The simple fact that we have
some mayor code changes forced into master just are the freeze (javelin, ucs and ipv6) and
immediately create a release branch isn't the way to go if we want a stable release. There
are numerous issues with the current state of master and hence the 4.1 branch like regression
bugs in the maven system that have been introduced by merging in old maven code with Javelin.

I personally don't feel we are in shape yet to make the current state of master into a release
worthy branch as it would seriously impair the ability of people to go in and fix stuff as
we have to deal with a release manager before patches are going into 4.1 branch.

In fact i feel so strong about it that i'm half a mind to start a vote to remove current 4.1
branch and set the next date to branch of from to a week from now. I don't feel confident
that the current state of the branch will result in a stable release without some serious
work going into it and that should happen on master.

Please have a look at the number of unit tests that have been pushed with the merges mentioned
above and the increase in code coverage reported by cobertura. Both of which show hardly any
changes even though mayor rewrites have been introduced in the inner workings of CloudStack.
I would expect to see for example detailed unittests on the handling of IPv6 and numerous
tests to ensure that the new spring framework is up to task. Currently i feel like i'm being
force into releasing something that i don't trust yet.

At collab12 one of the main themes that i was hearing all around what confidence in the code
base by testing. I would like the 4.1 release to be a show case if that way of thinking. We
have put out a very nice 4.0.0 release that the people i meet are very happy about. The next
release should be even better and inspire confidence that we are a project that is able to
deliver well tested and stable releases.

Sorry for being such an ass about this, but we are all working very hard on getting this release
out and i really want this to be the best release possible and not just a bunch of bolted-on

So what do you guys think?



From: Chip Childers []
Sent: Saturday, February 02, 2013 2:27 PM
To: <>
Subject: Re: [ACS41] 4.1 branch created

On Feb 1, 2013, at 11:42 PM, Mice Xia <> wrote:

> Does this mean features havent been merged into master will be postponed to 4.2?

Yes.  That was the idea with using a time-based release planning process.

> -Mice
> 2013/2/2 Alex Huang <>:
>> Kelven also mentioned he had to merge a few times because code was being changed
in master.  It is supposed to be frozen until this message from Chip.  Please respect the
instructions the release manager has given out.  Master is now open but 4.1 is now frozen.
 Please respect this even though you can check-in to 4.1.  If we find "features" being sneaked
in, then it would make sense for us to lockdown 4.1, which makes bug fixing and unit testing
checkins a laborious process.
>> --Alex
>>> -----Original Message-----
>>> From: Chip Childers []
>>> Sent: Friday, February 01, 2013 5:58 PM
>>> To:
>>> Subject: [ACS41] 4.1 branch created
>>> Hi all,
>>> Looks like Kelvin finished the merge of javelin into master, so I went
>>> ahead and branched master for the 4.1 release (after mistakenly doing
>>> the same for 4.2...  jumping the gun by a few months ;-) )
>>> This isn't a "locked down" branch right now, but I'd ask committers to
>>> respect the feature and improvement freeze in that branch.  Bug fixes,
>>> doc updates and other release stabilization activities are obviously
>>> expected.  Committers should feel free to commit directly into that
>>> branch until we hit the code freeze date).
>>> For non-commiter contributors, it might be best to actually send in
>>> patches that have been built against the 4.1 branch.  Committers
>>> taking these fixes should also consider applying them to master.  If
>>> there are conflicts in master (which may happen, as there were a
>>> couple of code-base refactoring activities, like switching packages
>>> from to org.apache.cloudstack), apply the fix into 4.1
>>> anyway, and inform the submitter that the patch has conflicts with
>>> master to get that sorted out (or you can fix it yourself).
>>> Shout if you have questions / concerns / flames.
>>> -chip

View raw message