[ovirt-devel] ovirt-engine-3.5 branching

[Itamar Heim]

On 07/08/2014 11:56 AM, Sandro Bonazzola wrote:
> Il 07/07/2014 09:50, Eyal Edri ha scritto:
>>
>>
>> ----- Original Message -----
>>> From: "Allon Mureinik" <amureini at redhat.com>
>>> To: "Antoni Segura Puimedon" <asegurap at redhat.com>
>>> Cc: devel at ovirt.org
>>> Sent: Sunday, July 6, 2014 11:20:13 AM
>>> Subject: Re: [ovirt-devel] ovirt-engine-3.5 branching
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Antoni Segura Puimedon" <asegurap at redhat.com>
>>>> To: devel at ovirt.org
>>>> Sent: Thursday, July 3, 2014 8:27:18 PM
>>>> Subject: Re: [ovirt-devel] ovirt-engine-3.5 branching
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Allon Mureinik" <amureini at redhat.com>
>>>>> To: "Oved Ourfali" <ovedo at redhat.com>
>>>>> Cc: "Piotr Kliczewski" <pkliczew at redhat.com>, devel at ovirt.org
>>>>> Sent: Thursday, July 3, 2014 4:57:55 PM
>>>>> Subject: Re: [ovirt-devel] ovirt-engine-3.5 branching
>>>>>
>>>>> I concur.
>>>>>
>>>>> There are too many flows broken on /master/ to consider the 3.5 branch
>>>>> anything remotely near "stable".
>>>>
>>>> Wouldn't it be better to keep the current branch as "stabilization branch"
>>>> and test extensively every patch that goes into it instead of keeping
>>>> adding
>>>> to the master branch and rebranch and then have the same or similar happen
>>>> in the next test day?
>>>>
>>>> If I remember correctly in the previous release cycle something similar
>>>> happened
>>>> in the engine an teams tried to push non critical or stabilization patches
>>>> after feature freeze. At the time, it was argued that this release cycle it
>>>> would be branch and backport.
>>>>
>>>> I realize, of course, that it is painstaking to backport a great amount of
>>>> patches, but this is a direct result of letting features get merged too
>>>> late
>>>> in the cycle and before being up to a certain standard of stability.
>>>>
>>>> I would say "let this backporting frenzy be a lesson to all to be more
>>>> conservative
>>>> with the timelines in the next cycle" but I understand the other side of
>>>> the
>>>> argument, so maybe instead we should just count with an extra week between
>>>> freeze and branching (note that this will delay review and merge of work
>>>> on master for the next feature reducing the chances of big features being
>>>> merged early-middle cycle.
>>>
>>> I agree with the sentiment, but I think your solution would be
>>> counter-productive.
>>>
>>> The main question here is what's the purpose of the stable branch?
>>> The way I understand it, the stable branch is a branch for you to build the
>>> system from, assert that the main functionality is working, and report bugs
>>> that need fixing before release.
>>>
>>> With the current "stable" branch, that's a losing effort. It's broken twelve
>>> ways from Sunday. Basic functionality does not work. Virtually every patch
>>> that fixes something in the master should also be applied to it, which in
>>> fact means we're manually rebasing, instead of letting git do it for us.
>>>
>>> This does not mean, however, that we shouldn't take time an retrospect how we
>>> got to this abysmal situation, and thinking of ways to prevent it in the
>>> future - it just means we should look forward instead of punishing ourselves
>>> for past transgressions.
>>
>> Update:
>> we're planning to do the branch from master (rebase from HEAD), tomorrow towards noon time.
>> if you have any commits that are relevant only for 3.6 and not for 3.5, please don't merge them yet
>> until we'll update the 3.5 stable branch.
>>
>> and email with the exact cutoff commits sha will be sent once the branch is updated.
>>
>> thanks,
>>
>> Eyal.
>
>
> Since it seems there are still work in progress on completing features with exceptions, maybe better to postpone the branch update to next week, on
> Monday 08:00 UTC.
>
> Any objection?

features with exceptions doesn't mean they don't need to carry the 
overhead of backporting. i don't think there is too much pressure on 
"non 3.5 items" going into master, but that would be one of the main 
reasons to branch.