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" <[email protected]> >>>> To: "Antoni Segura Puimedon" <[email protected]> >>>> Cc: [email protected] >>>> Sent: Sunday, July 6, 2014 11:20:13 AM >>>> Subject: Re: [ovirt-devel] ovirt-engine-3.5 branching >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Antoni Segura Puimedon" <[email protected]> >>>>> To: [email protected] >>>>> Sent: Thursday, July 3, 2014 8:27:18 PM >>>>> Subject: Re: [ovirt-devel] ovirt-engine-3.5 branching >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Allon Mureinik" <[email protected]> >>>>>> To: "Oved Ourfali" <[email protected]> >>>>>> Cc: "Piotr Kliczewski" <[email protected]>, [email protected] >>>>>> 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 _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
