Re: Proposal: Reorganization of the Project Management
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.