Proposal: Reorganization of the Project Management

[Dave Neary]

Hi Ayal,

On 03/09/2013 10:31 PM, Ayal Baron wrote:
>> General advice based on my experience with oVirt:
>> * I recommend a 6 month cadence with ~4 months feature development
>> and
>> ~2 months release preparation

<snip>

>> * Make regular point releases (alpha, beta 1, beta 2, RC1, whatever
>> they're called) before and after a release. I'm looking forward to
>> 3.2.1!
>
> if we have a 6 month release cycle, do you envision 1-2 point releases?
> e.g. 3.2.1 2 months after 3.2 and 3.2.2 2 months after that and then after another couple of months 3.3?

I was thinking we could lower the cost of making a point release to the 
point where we could have a release every month... like this:

February: 3.2.0 released
March: 3.2.1 released - contains fixes for important issues discovered 
post-release in 3.2.0 - in the meantime, feature proposal and 
prioritisation (and development) continues on the trunk
April: 3.2.2 released - only if there are significant bug fixes or new 
translations
May: 3.3.alpha1 released - in-progress work, contains some early 
features, aimed for testing to identify features that need additional 
work early. Release branch is made now.
June: 3.3.alpha2 released - corresponds to feature freeze. At this 
stage, incomplete features should no longer be committed. Work can start 
on testing, integration testing, bug day
July: 3.3.beta1 released - Corresponds to UI and string freeze - 
translations and docs, and release notes, should be underway already, 
but can hit full speed. Testing and bug fixing continues

August: 3.3.0 released

The only release that should take longer than a couple of hours to put 
out is 3.3.0 - the other releases are a tag in the source code, and a 
pointer to specific nightly builds.

Cheers,
Dave.

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13