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.child...@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.x...@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.hu...@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.child...@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 >
