Re: Proposal: Reorganization of the Project Management
----- Original Message -----
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:
I'm not sure I understand what below reduces cost of making the point release.
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
I have yet to see a month pass without important fixes.
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.
From this point there are no more point releases to 3.2 then, correct?
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
No longer committed to the 3.3.alpha2 branch you mean? since as you've stated above,
there shouldn't be a 'quiet' period in master as it deters contributors.
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.
I don't see how that is possible. 3.2.1 in this way will contain new features and
code which is not fully tested yet (negative flows etc) so you may come out with a release
which is less stable than the base version (3.2).
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