[ovirt-devel] ovirt-engine-3.5 branching

Tue Jul 8 08:56:29 UTC 2014

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?

> 
>>
>>
>>>
>>>>
>>>> wrt to holding off 3.6 features, I can confirm that from the storage side
>>>> nothing has been merged, and we can keep holding them back.
>>>>
>>>>
>>>> -Allon
>>>>
>>>> ----- Original Message -----
>>>>> From: "Oved Ourfali" <ovedo at redhat.com>
>>>>> To: devel at ovirt.org
>>>>> Cc: "Piotr Kliczewski" <pkliczew at redhat.com>
>>>>> Sent: Thursday, July 3, 2014 5:31:43 PM
>>>>> Subject: [ovirt-devel] ovirt-engine-3.5 branching
>>>>>
>>>>> Hi all,
>>>>>
>>>>> The test day revealed a large amount of issues. These issues are being
>>>>> addressed in the last few days.
>>>>> To avoid the need to back-port each and every one of them to the
>>>>> ovirt-engine-3.5 stable branch, I suggest to give a few days for that
>>>>> effort,
>>>>> and revisit it on mid next week, to asses it again and decide whether
>>>>> to
>>>>> do
>>>>> the branching then.
>>>>>
>>>>> I ask the different maintainers not to push 3.6 relevant material into
>>>>> master
>>>>> in the next few days, until the branching is done.
>>>>> To my knowledge no major (or any) patch related to 3.6 has been merge
>>>>> on
>>>>> master, but please correct me if I'm wrong.
>>>>>
>>>>> Thanks all for your efforts in stabilizing the version.
>>>>>
>>>>> Regards,
>>>>> Oved
>>>>> _______________________________________________
>>>>> Devel mailing list
>>>>> Devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>>
>>>> _______________________________________________
>>>> Devel mailing list
>>>> Devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>> _______________________________________________
>> Devel mailing list
>> Devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 

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