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