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

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?