Proposal: Reorganization of the Project Management

[Itamar Heim]

On 03/12/2013 11:39 AM, Dave Neary wrote:
> 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.

it also gets the patches for .el6 support in 3.2 as an exception this time.

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

if the branch is temporary, to only fix critical issues for that phase, 
then goes away and we rebase for the next branch - i'm fine with it. but 
since you can't assess how many patches would be needed, usually at 
early phases snapshots are used - snapshots are just taking master, 
testing it, fixing all broken things and taking master again for next 
snapshot (hence snapshots are usually weekly builds).
i think it is a better approach as a concept till the beta build.