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