incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [ACS41] 4.1 branch created
Date Sun, 03 Feb 2013 18:46:55 GMT
On Sun, Feb 3, 2013 at 2:03 AM, Hugo Trippaers
<HTrippaers@schubergphilis.com> 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

Mime
View raw message