Ok, I am perhaps confused because your comments about going through a release manager I thought were related to the code freeze stage, not feature freeze. Chip mentioned something about committers still being free to make changes in 4.1. So perhaps we should clear that up first.
I'm not at all against pushing back, I haven't really formed an opinion yet. I would like to hear what specifically would be accomplished in that week or so if we did push back. We would need to formulate some solid set of requirements that needed to be worked on, a specific set of tests or something to avoid sounding like we're just saying "take a week to make it better". I would suspect that the timeline keeps things close enough that people could work in master and pull into 4.1 over the next week or two, beyond that it does probably make sense to cancel the branch, but again that depends on my previous paragraph. On Sun, Feb 3, 2013 at 12:37 AM, Hugo Trippaers <htrippa...@schubergphilis.com> wrote: > 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 [shadow...@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" <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. >> >> 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 >> > >>
