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? > >> >> >>> >>>> >>>> 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" <[email protected]> >>>>> To: [email protected] >>>>> Cc: "Piotr Kliczewski" <[email protected]> >>>>> 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 >>>>> [email protected] >>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>> >>>> _______________________________________________ >>>> Devel mailing list >>>> [email protected] >>>> http://lists.ovirt.org/mailman/listinfo/devel >>>> >>> _______________________________________________ >>> Devel mailing list >>> [email protected] >>> http://lists.ovirt.org/mailman/listinfo/devel >>> >> _______________________________________________ >> Devel mailing list >> [email protected] >> http://lists.ovirt.org/mailman/listinfo/devel >> > _______________________________________________ > Devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel > -- 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
