> -----Original Message-----
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Monday, September 23, 2013 12:25 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [PROPOSAL] move away from time-based releases and/or revamp
> release process
>
> 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.
[Animesh>] His proposal is not just for master, but also for deciding the
release exit criterion and IMO is something we should follow for 4.3.0 and
onwards
>
> > >
> > > 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.
[Animesh>] RC is not thrown in it is discussed as part of the release schedule.
After the code-freeze date everyone is expected to complete their integration
testing by RC date. In fact I had sent numerous reminders prior to the first RC
starting from 2 weeks before the proposed RC date.
