Oh yes, of course. What these people would be looking for are bug fix releases. They want to wait for 4.0.1, not 4.1.0. On Feb 3, 2013 12:54 AM, "Marcus Sorensen" <shadow...@gmail.com> wrote:
> One more thing, I think people waiting for non .0 releases probably > will be disappointed. My impression was that our versioning doesn't > really work that way, major revisions are more related to API > compatibility, correct? > > On Sun, Feb 3, 2013 at 12:51 AM, Rohit Yadav <bhais...@apache.org> wrote: > > On Sun, Feb 3, 2013 at 1:07 PM, 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. > > > > As per the timeline, we have roughly two months (~end of march) till > > 4.1 release. So, initially I thought about just working for another > > month on master and then creating the 4.1 branch, but then the issue > > is with code freeze, people may want to commit new features. While I > > would just want what you're suggesting, but can we enforce that no one > > commits any new feature work on master? (this is doable if we ask > > people to work on their feature branches). > > > >> 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. > > > > IMO 4.2 would be the actual version we would see radical changes, > > hoping we fix a lot of leftover tasks, adapt the codebase as per new > > design. > > > > Regards. > > > >> > >> 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 > >>> > > >>> >
