Re: [ovirt-devel] ovirt-engine-3.5 branching

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(a)redhat.com&gt; >>> To: "Antoni Segura Puimedon" <asegurap(a)redhat.com&gt; >>> Cc: devel(a)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(a)redhat.com&gt; >>>> To: devel(a)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(a)redhat.com&gt; >>>>> To: "Oved Ourfali" <ovedo(a)redhat.com&gt; >>>>> Cc: "Piotr Kliczewski" <pkliczew(a)redhat.com&gt;, devel(a)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.