[ovirt-devel] ovirt-engine-3.5 branching

[Sandro Bonazzola]

Il 08/07/2014 15:10, Itamar Heim ha scritto:
> 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.
> 


Ok, so scheduling branch refresh for tomorrow. Will send an email in a couple of minutes.


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com