+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. Thanks /sudha -----Original Message----- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Sunday, February 03, 2013 10:47 AM To: cloudstack-dev@incubator.apache.org Subject: Re: [ACS41] 4.1 branch created On Sun, Feb 3, 2013 at 2:03 AM, Hugo Trippaers <htrippa...@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
