Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <20121101032447.GA22295@kodos>
References: 
 <CAKprHVYjby-15N_ecDR8+AELueT2uRb1ouZjvSPFvcTV1S4=eA@mail.gmail.com>
	<4FB26147.1060307@suse.com>
	<CAKprHVYJZNwwfrixOJBvmoZNB+xTtakTk79e5Rw8YvVXEEbDBA@mail.gmail.com>
	<60E64BEC-7367-4E72-95C7-DB319D3DB592@stratosec.co>
	<4FB65E06.5070109@suse.com>
	<CAKprHVZPZjAhKHObdA-MMLJGt2QAh=QgKdBRcyaNJKxo7mrfKA@mail.gmail.com>
	<CA+96GG5Mitx=1UgHsu5Zv9jxtpLxXT1MvE4C4QNtpX8tUAaUGA@mail.gmail.com>
	<20121101032447.GA22295@kodos>
Date: Thu, 1 Nov 2012 20:14:56 -0400
Message-ID: 
 <CA+96GG7=833wwtzHZWyhm9ButLzFjZLOWdfavnODU_ka=9U52Q@mail.gmail.com>
Subject: Re: [DISCUSS] releases going forward
From: Chip Childers <chip.childers@sungard.com>
To: cloudstack-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Oct 31, 2012 at 11:24 PM, Joe Brockmeier <jzb@zonker.net> wrote:
> On Wed, Oct 31, 2012 at 08:26:05PM -0400, Chip Childers wrote:
>> Digging this out of the past, IIRC, we never got around to resolving
>> the time period for releases.  We should come to a conclusion on this
>> topic!  I'd like to propose that we follow a 4 month release cycle for
>> non-bug fix releases.
>
> Sounds reasonable.
>
>> Generally, it would mean a schedule that would look something like
>> this (M=Month and W=Week):
>> M1 through M2 - Features are being developed in branches, and merged
>> into master over the course of these two months
>> M2 W4 - Feature freeze (and release branch is cut).
>> M3 W1 through M4 W1 - Doc Updates and Testing
>> M4 W1 - Docs Freeze
>> M4 W2 - Final regression testing / bug fixes / doc fixes
>> M4 W3 - First RC cut and opened for voting...  Wash rince repeat until
>> an RC is voted to be released
>
> Though we don't yet have a big translation community, we should probably
> plan for translations in here somewhere after docs freeze. 3-4 weeks
> should give time for translations.

Let's see if I can work that into the schedule cleanly...

> Ideally, though - docs should be updated through the process. (i.e.,
> let's not wait until M3W1 to start doc updates, please.)

Absolutely true.  I just think that we need to call out the feature
freeze as being the point in time that documentation can start being
reviewed in earnest, against the features themselves (knowing that
they may be buggy).

> I assume M4 W3 is also code freeze?

Yes.  IMO, that means that the RC is cut and only issues identified as
release blockers are being fixed from that point forward.  I'd suggest
that the model of a limited group of people cherry picking commits
into the release branch from that point forward worked OK for us
during 4.0.0 (although we were a bit sloppy about it).

> Do we plan milestone releases between M2 W4 and M4 W3, or are we
> assuming folks will just use builds out of Jenkins or ...?

I'd suggest that we use jenkins here, but I'd like to see the output
of the build jobs actually push to package repos (perhaps hosted on
the build server).  The single file download, with install.sh, isn't
what we should be testing...  since that's not what we release.

>> If we can reach a consensus on this, I'll be happy to draft up a
>> schedule with specific dates for our 4.1.0 release.
>>
>> Thoughts, comments, flames?
>
> Looks reasonable to me.

Great - Drafting now.

> Best,
>
> Joe
> --
> Joe Brockmeier
> Twitter: @jzb
> http://dissociatedpress.net/
>