cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sudha Ponnaganti <>
Subject RE: [ACS41] 4.1 branch created
Date Sun, 03 Feb 2013 19:44:18 GMT
+1 for 4.1 branching. Master would not be stable and closing 4.1 would be very difficult if
the branch is cut much later as teams would be checking in new features in to master. 
There is of course possibility to hold these features by other means like holding merge and
holding review branches. 

We are running automated regressions offline on master and you must have been seeing some
defects coming in since last week. Will be testing new features starting this week. Teams
have posted new test plans. Waiting on review feedback but not holding back because of that.


-----Original Message-----
From: Chip Childers [] 
Sent: Sunday, February 03, 2013 10:47 AM
Subject: Re: [ACS41] 4.1 branch created

On Sun, Feb 3, 2013 at 2:03 AM, Hugo Trippaers <> wrote:
> 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.

I disagree with the statement that it's too early to have cut the release branch, but I think
we have different understandings of my intent in cutting that branch.  I completely agree
that it's not a release quality branch right now.  Far from it.  This quality level is problematic
to me, but it's a different issue from freeing up master for new features and further refactoring
work that will be part of the feature release that's after 4.1.0.

The intent of the 4.1 branch is to (1) freeze new features from going into the 4.1 release,
(2) provide us with a branch to focus our release stabilization efforts, and (3) allow features
to continue to merge into master for our next feature release after 4.1.0 (which may be 5.0.0
or 4.2.0, depending on some of the API discussions).

Also, one other key point.  I'm not interested in taking responsibility for cherry picking
changes from master to 4.1 right now, and will not be doing so!  The working schedule for
4.1.0 has that level of branch freeze only after 2013-02-28.

Yes, cutting a branch now means that committers have to take extra time to ensure fixes go
into master AND 4.1.  I'd rather have that situation, than continue to block new features
and architectural modifications in master.  The best way for time-based releases to get better,
is for us to ensure that changes happen as early in the cycle as possible.  We flooded changes
into master just before the agreed upon cutoff date, which is at best sub-optimal.

> 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.

So you don't actually have to start a vote on it.  You've got the right to veto the 4.1 branch
if you'd like to. ;-)  Please consider my other points before taking that action though, and
please include an alternative plan!

> 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.

I completely concur with the concerns about unit testing.  I'm actually pretty disappointed
in the lack of attention to including automated tests of some sort with each new feature.
 This lack of attention seems to contradict what I understood to be the general community
consensus that we need to include tests with every new feature.  How do we want to fix this
moving forward?  Should the committers veto any commit that doesn't increase test coverage
wherever possible?

> 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.

You're not being an ass at all.  I think you're very appropriately raising the right concerns.
 We just disagree with the intent of the branch!

> So what do you guys think?
> Cheers,
> Hugo

View raw message