Proposal: Reorganization of the Project Management

[Dave Neary]

Hi,

On 03/12/2013 10:14 AM, Itamar Heim wrote:
> On 03/11/2013 10:42 PM, Ayal Baron wrote:
 >> Dave Neary wrote:
>>> 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.

<snip>

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

<snip>

>>> Does that help explain what I have in mind better?
>>
>> Yes, it is fine, but saying that making the point release is a no
>> brainer is misleading since you take a major hit during the entire
>> period you have a branch (and you have a branch almost all the time -
>> 3.2.1, 3.2.2, 3.3.alpha1, 3.3.alpha2...).

Yes, that's correct - all of the time when you have a release branch, 
you have the additional cost of merging back, and the longer the release 
branch lasts, the bigger the cost becomes.


>> In fact, you need to branch 3.2.1 from 3.2 and not from trunk
>> otherwise you immediately get patches that are not about stability.
>> If we do this we'd need to define the criteria of what is backported
>> and what is not.

3.2.1 does not get a branch, it's a tag on the 3.2 branch. The criteria 
for what gets backported and what is not is straightforward, I think - 
the only thing that gets backported are bug fixes to released features - 
no new features.

> we don't want to deter contributions so we don't want to block continued
> work on master.
> but taking the 3.3 stabilization branch earlier than alpha will only
> mean it gets less bug fixes due to the overhead of backporting them.
> I think it is fine to specify beta is in two weeks, and only bug fixes
> should go in at that period. or we don't do this. but considering the
> amount of bug fixes around the "alpha" period, doesn't make sense to
> branch before it (the risk from new features is lesser from amount of
> bugs which won't be backported in my view).

As you can see, I am suggesting branching after feature freeze - after 
alpha releases, and before beta releases. It could be delayed a few 
days, perhaps a couple of weeks, for sure, but I would like to have a 
place to land new features that are ready to be integrated after the 
feature freeze, but which we have agreed should not go into the next 
stable release. IMHO, that place should be the trunk (and that is only 
possible if you have already made a release branch).

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