Next Release Planning

[Yaniv Kaul]

On 08/23/2012 09:05 AM, Livnat Peer wrote:
> On 22/08/12 16:56, Dave Neary wrote:
>> Hi,
>>
>> On 08/22/2012 11:02 AM, Livnat Peer wrote:
>>> About branching policy I'm not sure if we have one, except for creating
>>> a branch before release for stabilization.
>> Allow me to rephrase & make this concrete:
>>
>> In the GNOME project, modules branch as close as possible to release -
>> usually on the release day, or when making a release candidate. In
>> effect, the developers agree to work on new features only on branches,
>> and the trunk is where most of the pre-release work gets done. Branches
>> get merged back into the trunk when they're ready, and not before - and
>> never when we're in feature freeze.
>>
>> We branch a stable branch for fixes to bugs in the stable release, and
>> those are as a matter of course fixed in trunk first, and back-ported to
>> the stable branch. We have time-based stable releases of the stable
>> branch during the first 6 weeks of a release cycle to get those fixes
>> out to distros & users.
>>
>> My understanding of what you've said so far is that at some point (long
>> before the August 8th release date), a 3.1 release branch was made, and
>> only bug fixes to features which had been included in 3.1 were added to
>> that branch from that date. In the meantime, feature and bug fixing work
>> continued also on the stable branch, but not all of those bug fixes were
>> back-ported to the pre-release branch. I'm guessing that branch was made
>> when we hit 3.1 feature freeze?
>>
>> If my understanding is correct, you then have a period of several months
>> (because of the release date slip) when the 3.1 branch is not moving
>> very much, and everyone is working on the trunk branch, including
>> developing new features. The end result is that when the release is
>> made, there is already a big diff with trunk, and as you point out,
>> cherry-picking bug fixes for inclusion on a 3.1 branch is a lot of work.
>>
>> In my mind, the work on 3.2 started when we made the 3.1 branch, in this
>> scenario, so perhaps we're already too late to discuss what needs to be
>> included in the 3.2 release - perhaps we should simply work on
>> finishing/stabilising what we have now for release?
>>
> +1, I suggest that instead of stabilizing what we have now, we'll send a
> release date and a feature freeze (FF) date to the dev lists, and see if
> there are any comments about the plan, maybe postponing FF by a week or
> so can give us more features etc.
> On the agreed FF date we'll create the 3.2 branch and ask all
> stabilization patches to be cherry picked to the 3.2 branch.

I may be a bit biased because I'm from QE, but I do suggest a different 
path - remain stable at all times.
The huge delay in releasing 3.1 due to quality issues supports this.
It means development may be a bit slower, but it'll pay off in release 
time and quality.
Y.

>
>
> I think we should discuss now what should happen with the next-next
> release :)
> after releasing 3.2 we'll have the same dilemma we are having today. How
> will we make the decision if the following release is 3.3 or 3.2.1, do
> we want to create 3.2.1 on our 3.2 release date and ask for all
> stabilization patches to be back ported there? and if we see that we
> want to release 3.3 at the end and no need for 3.2.1 will all the cherry
> picking be for vane?
>
>> Again, excuse me if I'm over-stepping bounds, I'm just trying to figure
>> out where the work in the project is getting done, and what that implies
>> for this thread.
> I think it is a useful discussion and can help us going forward. There
> is a great value in your participation and in any experience someone
> brings to the table.
>
>> Cheers,
>> Dave.
>>
> _______________________________________________
> Board mailing list
> Board at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/board