On Sun, Feb 3, 2013 at 10:46 AM, Chip Childers <chip.child...@sungard.com> wrote: > 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.
I am completely agree with Chip's statement here. It's a feature freeze branch, which still means tons of bugs are ahead. Take Linux kernel for example, Linus open the merge window, and pull from other contributor almost every 3 months - last 2 or 3 weeks each(thousands of commits I think), then cut RC1, which means, feature is done, now only bug fixes for these features. Most of time, Linux kernel RC1 is only compilable, and totally broken for everyone. That's what we need to fix after that - we just need to ensure that no feature after the cut, which is the source of never "convergence"(stable). That's the purpose of branch. The stabilization of Linux kernel would take mostly three months, until RC6 or RC7 mostly. Also, I am competely agree with Chip's saying of cherry-picking. It's too early for cherry-picking, just make no sense for release manager to pick up probably tens of commits per day. That's not expected. Developer would take the responsibility. --Sheng > >> 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
