cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <>
Subject RE: [ACS41] 4.1 branch created
Date Sun, 03 Feb 2013 07:23:54 GMT
I understand the reservations as well, and I think everyone has reached the
consensus that we should both include better test coverage and reserve
large changes for the beginning of the dev cycle. But my impression was
that this was just a feature freeze, and we really have another few months
to harden things.

I'm not sure it makes sense to hold off on the cut, as if we do, I think
we'd be pushing people off from merging features to master (or risk
continuously pushing out), and we can just address the things anyway and
pull them into the 4.1 branch without interrupting development. I wasn't
under the impression that the 4.1 branch would be hard to work on, just
that we shouldn't be adding features.

Are you thinking there should be a regular moratorium or something similar
just before the cut, so that the quality of the features as a whole can be
evaluated, or are you just concerned that the last minute features didn't
get proper review? I think that as long as there's a time-based release
were going to have features rushed, we either need to be OK with it and
allow for time and ability to fix it afterward, or have some very stringent
quality control prior to merge. We can maybe start with the former and work
toward the latter.
On Feb 3, 2013 12:04 AM, "Hugo Trippaers" <>

> 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 features.
> So what do you guys think?
> Cheers,
> Hugo
> ________________________________________
> 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
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message