Proposal: Reorganization of the Project Management

Ayal Baron abaron at redhat.com
Mon Mar 11 16:15:59 UTC 2013



----- 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
> 



More information about the Arch mailing list