On Sep 23, 2013 1:03 PM, "Animesh Chaturvedi" <animesh.chaturv...@citrix.com> wrote: > > > > > -----Original Message----- > > From: Marcus Sorensen [mailto:shadow...@gmail.com] > > Sent: Monday, September 23, 2013 11:38 AM > > To: dev@cloudstack.apache.org > > Subject: [PROPOSAL] move away from time-based releases and/or revamp > > release process > > > > Guys, I think we are not currently in a state to handle time-based > > releases. Until we can cut master at any time and have it releasable, > > or at least at a reasonable RC-level matching minimum tested > > requirements, it's just going to continue to be an exercise in > > frustration to cut RCs simply because we hit a deadline. > [Animesh>] David is going to propose Release Criterion up for discussion as per his thread [1]
I see that thread more about defining what minimum bar we should always have master at in order to meet time-based releases. Its where we want to go, but not what to do in the meantime. > > > > Maybe we can get away with sticking to time-based if we revamp our > > schedule and procedures, I don't know, but in light of how 4.1 (dragged > > on so long that some were seriously considering skipping/not releasing > > it with 4.2 on its heels) and 4.2 (six rounds of votes so > > far) have worked it's probably worth discussing. > > > > Any suggestions on what might be better? It's been mentioned in the past > > that it's a chicken-egg thing, many really don't try it until we hit an > > RC, which causes multiple iterations. I do agree that many don't take it > > seriously until we start cutting artifacts, but maybe we do this in a > > more deliberate fashion instead of jumping right to the vote. After > > feature/code freeze, cut some alpha artifacts, wait a week, cut alpha2 > > or some beta artifacts, etc, and then at some point anyone can propose > > that certain artifacts (or a new set of artifacts) be put up for a vote > > as an RC. This gives us a way to signal that we're gearing up for > > release and gives plenty of time for people to test their components, or > > see the [PROPOSAL] and say 'oh crap, I had better test my stuff', prior > > to cutting an RC. Maybe this wouldn't help in practice, but I think > > right now we go from telling the community "code is frozen, don't check > > anything in unless its a bug fix" to "here's our RC, try it out", > > without a formal testing window. > > I realize the whole thing should be a testing window, but I don't think > > it's conveyed well. > > [Animesh>] After the code freeze is all the stabilization and integration testing phase and has been documented at [2]. No one should be waiting until the RC to test their components for the first time. It should be happening after code freeze. > > [1] http://markmail.org/thread/wlaq4zg36xnpgsjm > [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases > Got it. As mentioned I realize that the whole time there is supposed to be testing, but its not really working that way in practice. People are volunteers, they forget where things are, or they dont want to mess with it unless there is an indication that its semi-stable, and then suddenly an RC is thrown over the fence and we go through iterations of RC. By the time the RC comes through we should be done testing and just verify that someone's last minute bug fix didn't cause a regression or something.
