cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hugo Trippaers <HTrippa...@schubergphilis.com>
Subject RE: [ACS41] 4.1 branch created
Date Sun, 03 Feb 2013 07:37:33 GMT
Hey Marcus,

We do have another month  or soto fix things. My main worry is the amount of things that we
still have to fix. The current consensus is that we have a release manager who does the cherry
picking of fixes from master to the branch. If we have sizable number of fixes this might
quickly become a bottle neck and unreasonably burden the poor guy assigned to the job (remember
that its a volunteer run project). If we are able to work directly on the 4.1 branch we run
the risk that 4.1 and master diverge to a point where they are increasingly difficult to realign
and we get the same issues as with the javelin merge when we finish up the 4.1 release and
get in shape for the 4.2 release.

Normally i would be al for sticking to the process, but in this particular case we have several
large features (and in the case of javelin radical architecture changes) pushed in at the
very last moment possible. Combined with the poor shape of testing at the moment this calls
for extra caution. This is going to be the 4.1 release, in my experience a lot of enterprise
folks will hold off on .0 release and wait for .1 releases before the decide to upgrade or
not. It's also our second release and folks might be waiting for that as well, not really
trusting our first release yet. So i'm really aiming for this release to be the highest quality
possible, i personally find this more important than sticking to the plan (at this time).
And as you mentioned, the plan actually calls for large features to be merged at the beginning
of the cycle, not at the end in a rush.

Cheers,

Hugo

________________________________________
From: Marcus Sorensen [shadowsor@gmail.com]
Sent: Sunday, February 03, 2013 8:23 AM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [ACS41] 4.1 branch created

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" <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.
>
> 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 [chip.childers@sungard.com]
> Sent: Saturday, February 02, 2013 2:27 PM
> To: <cloudstack-dev@incubator.apache.org>
> Subject: Re: [ACS41] 4.1 branch created
>
> On Feb 1, 2013, at 11:42 PM, Mice Xia <weiran.xia1@gmail.com> 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 <Alex.Huang@citrix.com>:
> >> 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 [mailto:chip.childers@sungard.com]
> >>> Sent: Friday, February 01, 2013 5:58 PM
> >>> To: cloudstack-dev@incubator.apache.org
> >>> 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 com.cloud 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
> >
>

Mime
View raw message