Proposal: Reorganization of the Project Management
Itamar Heim
iheim at redhat.com
Tue Mar 12 09:14:39 UTC 2013
On 03/11/2013 10:42 PM, Ayal Baron wrote:
>
>
> ----- Original Message -----
>> 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?
>
> 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...).
> The further you are from the last release the more difficult it is to backport from trunk to the branch (3.2.2 has to be based on 3.2.1 and not directly from trunk for stability).
> 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.
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).
>
>
>>
>> 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
>>
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>
More information about the Board
mailing list