Proposal: Reorganization of the Project Management

[Dave Neary]

Hi,

On 03/11/2013 05:15 PM, Ayal Baron wrote:
>> 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.

Just this:

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

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

It's always possible, but that's the general idea. You're 2 months from 
the stable release, no new features go in the release branch, and you 
need to concentrate on getting the next release out.

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

Let me explain the branching strategy below - it's pretty standard in 
several open source projects, but maybe people aren't familiar with it.

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

OK - here's a quick ASCII Art branching strategy for a release cycle.

If everything is committed to trunk, your branch tree looks like this:

Trunk
   |
   |  Feature 1
   +---+
   |   |     Feature 2
   +---+---------+
   |   |         |
   |   |         |
   +---+ Merge   |
   |             |
   +-------------+ Merge
   |
   |


Now, you want to make a new major release. At feature freeze (when all 
features to be included are complete), you create a release branch.

Trunk
   |
   |                       3.3 release branch
   +---------------------------+ <- Feature freeze/branch creation
   |                           |
   |                           |
   |                           |
   |  Feature                  |
   +---+                       |
   |   |      Merge fix        |
   +---+---------------------> |
   |   |                       |
   |   |                       |
   +---+ Merge                 |
   |                           X <- 3.3.beta1 release
   |                           |
   |          Merge fix        |
   +-------------------------> |
   |                           |

Features and bug fixes continue to get done on the trunk, and those 
which are for the 3.3 release get merged into the 3.3 release branch. 
3.3 releases are made off the 3.3 release branch.

The 3.3.0, 3.3.1 and 3.3.2 releases are all tagged on the 3.3 release 
branch.

Development continues on the trunk throughout this time. At some point, 
the difficult part of this (committing fixes to the trunk and then 
merging them to the 2.3 branch) slows down or stops, and everyone is 
once again concentrating on the trunk, until such time as the 3.4 or 4.0 
(or whatever you decide to call it) release branch is created.

Once we "abandon" the 3.3 branch, there is no point in continuing to 
make point releases there. It serves the project better to have a period 
where everyone is concentrating on implementing new features and 
integrating them into the trunk, rather than having attention split 
between maintenance and new development indefinitely. In general, 6 
weeks after a release is enough time to identify and take xcare of the 
biggest issues in the release.

Does that help explain what I have in mind better?

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