incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sheng Yang <>
Subject Re: [ACS41] 4.1 branch created
Date Sun, 03 Feb 2013 19:26:43 GMT
On Sun, Feb 3, 2013 at 10:46 AM, Chip Childers
<> wrote:
> 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.

I am completely agree with Chip's statement here.

It's a feature freeze branch, which still means tons of bugs are
ahead. Take Linux kernel for example, Linus open the merge window, and
pull from other contributor almost every 3 months - last 2 or 3 weeks
each(thousands of commits I think), then cut RC1, which means, feature
is done, now only bug fixes for these features. Most of time, Linux
kernel RC1 is only compilable, and totally broken for everyone. That's
what we need to fix after that - we just need to ensure that no
feature after the cut, which is the source of never
"convergence"(stable). That's the purpose of branch. The stabilization
of Linux kernel would take mostly three months, until RC6 or RC7

Also, I am competely agree with Chip's saying of cherry-picking. It's
too early for cherry-picking, just make no sense for release manager
to pick up probably tens of commits per day. That's not expected.
Developer would take the responsibility.


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