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
I concur. There are too many flows broken on /master/ to consider the 3.5 branch anything remotely near "stable". 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@redhat.com> To: devel@ovirt.org Cc: "Piotr Kliczewski" <pkliczew@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Allon Mureinik" <amureini@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: "Piotr Kliczewski" <pkliczew@redhat.com>, devel@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.
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@redhat.com> To: devel@ovirt.org Cc: "Piotr Kliczewski" <pkliczew@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Antoni Segura Puimedon" <asegurap@redhat.com> To: devel@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@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: "Piotr Kliczewski" <pkliczew@redhat.com>, devel@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@redhat.com> To: devel@ovirt.org Cc: "Piotr Kliczewski" <pkliczew@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Allon Mureinik" <amureini@redhat.com> To: "Antoni Segura Puimedon" <asegurap@redhat.com> Cc: devel@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@redhat.com> To: devel@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@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: "Piotr Kliczewski" <pkliczew@redhat.com>, devel@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.
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@redhat.com> To: devel@ovirt.org Cc: "Piotr Kliczewski" <pkliczew@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Eyal Edri" <eedri@redhat.com> To: devel@ovirt.org Cc: "Antoni Segura Puimedon" <asegurap@redhat.com>, "Allon Mureinik" <amureini@redhat.com>, "Oved Ourfali" <ovedo@redhat.com>, "Sandro Tanaka" <stanaka@redhat.com> Sent: Monday, July 7, 2014 10:50:41 AM Subject: Re: [ovirt-devel] ovirt-engine-3.5 branching
----- Original Message -----
From: "Allon Mureinik" <amureini@redhat.com> To: "Antoni Segura Puimedon" <asegurap@redhat.com> Cc: devel@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@redhat.com> To: devel@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@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: "Piotr Kliczewski" <pkliczew@redhat.com>, devel@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. Why are we rebasing? Is there anything in the stable branch that isn't in master? Shouldn't we just delete this branch, and branch a new one from HEAD?
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.
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@redhat.com> To: devel@ovirt.org Cc: "Piotr Kliczewski" <pkliczew@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
yes, basically the same thing. no issue in deleting the branch and re-creating, just semantics. e. ----- Original Message -----
From: "Allon Mureinik" <amureini@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: devel@ovirt.org, "Antoni Segura Puimedon" <asegurap@redhat.com>, "Oved Ourfali" <ovedo@redhat.com>, "Sandro Tanaka" <stanaka@redhat.com> Sent: Monday, July 7, 2014 2:22:21 PM Subject: Re: [ovirt-devel] ovirt-engine-3.5 branching
----- Original Message -----
From: "Eyal Edri" <eedri@redhat.com> To: devel@ovirt.org Cc: "Antoni Segura Puimedon" <asegurap@redhat.com>, "Allon Mureinik" <amureini@redhat.com>, "Oved Ourfali" <ovedo@redhat.com>, "Sandro Tanaka" <stanaka@redhat.com> Sent: Monday, July 7, 2014 10:50:41 AM Subject: Re: [ovirt-devel] ovirt-engine-3.5 branching
----- Original Message -----
From: "Allon Mureinik" <amureini@redhat.com> To: "Antoni Segura Puimedon" <asegurap@redhat.com> Cc: devel@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@redhat.com> To: devel@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@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: "Piotr Kliczewski" <pkliczew@redhat.com>, devel@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. Why are we rebasing? Is there anything in the stable branch that isn't in master? Shouldn't we just delete this branch, and branch a new one from HEAD?
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.
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@redhat.com> To: devel@ovirt.org Cc: "Piotr Kliczewski" <pkliczew@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Il 07/07/2014 09:50, Eyal Edri ha scritto:
----- Original Message -----
From: "Allon Mureinik" <amureini@redhat.com> To: "Antoni Segura Puimedon" <asegurap@redhat.com> Cc: devel@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@redhat.com> To: devel@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@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: "Piotr Kliczewski" <pkliczew@redhat.com>, devel@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?
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@redhat.com> To: devel@ovirt.org Cc: "Piotr Kliczewski" <pkliczew@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
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@redhat.com> To: "Antoni Segura Puimedon" <asegurap@redhat.com> Cc: devel@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@redhat.com> To: devel@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@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: "Piotr Kliczewski" <pkliczew@redhat.com>, devel@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.
Il 08/07/2014 15:10, Itamar Heim ha scritto:
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@redhat.com> To: "Antoni Segura Puimedon" <asegurap@redhat.com> Cc: devel@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@redhat.com> To: devel@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@redhat.com> To: "Oved Ourfali" <ovedo@redhat.com> Cc: "Piotr Kliczewski" <pkliczew@redhat.com>, devel@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.
Ok, so scheduling branch refresh for tomorrow. Will send an email in a couple of minutes. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
participants (6)
-
Allon Mureinik -
Antoni Segura Puimedon -
Eyal Edri -
Itamar Heim -
Oved Ourfali -
Sandro Bonazzola