4:20 a.m.
----- Original Message -----
From: "Antoni Segura Puimedon" <asegurap(a)redhat.com>
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>
> To: "Oved Ourfali" <ovedo(a)redhat.com>
> Cc: "Piotr Kliczewski" <pkliczew(a)redhat.com>, 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.
>
> 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" <ovedo(a)redhat.com>
> > To: devel(a)ovirt.org
> > Cc: "Piotr Kliczewski" <pkliczew(a)redhat.com>
> > 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
> > Devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel