[nova] Backporting test refactors to stable/train
From Red Hat's point of view, we will have to care about stable/train for *very* long time, so we'd like to do everything we can to make our
Hey Elod and Vlad (and the ML, cc'ed) This is continuing the conversation Elod and I had on IRC. The immediate context is [1], which is a test refactor backport that in turn enables conflict-free backporting of at least two fixes. lives easier, including backportings things are aren't strictly necessary (like test refactors) in order to greatly facilitate future backports, which tend to be of the "func reproducer test + actual fix" variety. Elod made the excellent point that while this approach does make backports to train much easier to both write and review, it also "postpones" all of the manual conflict resolution work onto anyone doing stable/stein backports. I went and gathered data. I looked at the last 6 months of backports in Gerrit. At the time of this writing, stable/train 72 [2] had and stable/stein had 24 [3]. Out of the latter, Vlad Gusev was the main non-Red Hat contributor. So my proposal is simple: I'm willing to help resolve conflicts in stable/stein backport for folks like Vlad, if it means making backports to stable/train easier. I'm confident that it would still mean an overall reduction in man-hours for backports, even if I become personally on the hook to deal with the fallout of backporting test refactors to stable/train. Cheers! [1] https://review.opendev.org/c/openstack/nova/+/791481 [2] https://review.opendev.org/q/project:openstack/nova+branch:stable/train+-age... [3] https://review.opendev.org/q/project:openstack/nova+branch:stable/stein+-age...
On 14-09-21 13:55:14, Artom Lifshitz wrote:
Hey Elod and Vlad (and the ML, cc'ed)
This is continuing the conversation Elod and I had on IRC. The immediate context is [1], which is a test refactor backport that in turn enables conflict-free backporting of at least two fixes.
From Red Hat's point of view, we will have to care about stable/train for *very* long time, so we'd like to do everything we can to make our lives easier, including backportings things are aren't strictly necessary (like test refactors) in order to greatly facilitate future backports, which tend to be of the "func reproducer test + actual fix" variety.
Elod made the excellent point that while this approach does make backports to train much easier to both write and review, it also "postpones" all of the manual conflict resolution work onto anyone doing stable/stein backports.
I can't say I agree with the objection here but regardless I think the ship has already sailed on us backporting many of these test refactors to stable/train. We have already backported so by manually resolving conflicts and that would now conflict again with any attempt to backport the refactors. At least that has been my experience the last few times I tried to do this and I've now given up and manually resolved conflicts, for example: https://review.opendev.org/c/openstack/nova/+/785847 Going forward however and with my dusty old Red Hat on I want to try to do this as much as possible back to stable/wallaby to allow fixes to flow through our stable branches as seamlessly as possible. I don't see why such contributions should be blocked, the work required to resolve these conflicts would eventually have to be done by someone, pushing that to contributors who care about a given older release only seems fair IMHO.
I went and gathered data. I looked at the last 6 months of backports in Gerrit. At the time of this writing, stable/train 72 [2] had and stable/stein had 24 [3]. Out of the latter, Vlad Gusev was the main non-Red Hat contributor.
Slight tangent but only 20 landing for train and 10 landing for stein. If anyone is interested in becoming a stable core on Nova please feel free to reach out as we could really use more reviewers.
So my proposal is simple: I'm willing to help resolve conflicts in stable/stein backport for folks like Vlad, if it means making backports to stable/train easier. I'm confident that it would still mean an overall reduction in man-hours for backports, even if I become personally on the hook to deal with the fallout of backporting test refactors to stable/train.
Well that's good of you Artom but I don't think that should be required to land such backports on a given stable branch. Cheers, Lee
[1] https://review.opendev.org/c/openstack/nova/+/791481 [2] https://review.opendev.org/q/project:openstack/nova+branch:stable/train+-age... [3] https://review.opendev.org/q/project:openstack/nova+branch:stable/stein+-age...
-- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
On Tue., Sep. 14, 2021, 15:57 Lee Yarwood, <lyarwood@redhat.com> wrote:
On 14-09-21 13:55:14, Artom Lifshitz wrote:
Hey Elod and Vlad (and the ML, cc'ed)
This is continuing the conversation Elod and I had on IRC. The immediate context is [1], which is a test refactor backport that in turn enables conflict-free backporting of at least two fixes.
From Red Hat's point of view, we will have to care about stable/train for *very* long time, so we'd like to do everything we can to make our lives easier, including backportings things are aren't strictly necessary (like test refactors) in order to greatly facilitate future backports, which tend to be of the "func reproducer test + actual fix" variety.
Elod made the excellent point that while this approach does make backports to train much easier to both write and review, it also "postpones" all of the manual conflict resolution work onto anyone doing stable/stein backports.
I can't say I agree with the objection here but regardless I think the ship has already sailed on us backporting many of these test refactors to stable/train.
Maybe, but at least in some cases it's still possible, like my [1] link in my previous message. We have already backported so by manually resolving conflicts and that
would now conflict again with any attempt to backport the refactors. At least that has been my experience the last few times I tried to do this and I've now given up and manually resolved conflicts, for example:
https://review.opendev.org/c/openstack/nova/+/785847
Going forward however and with my dusty old Red Hat on I want to try to do this as much as possible back to stable/wallaby to allow fixes to flow through our stable branches as seamlessly as possible.
I don't see why such contributions should be blocked, the work required to resolve these conflicts would eventually have to be done by someone, pushing that to contributors who care about a given older release only seems fair IMHO.
Fair, hard to argue with "if you care about something, put in the work."
I went and gathered data. I looked at the last 6 months of backports
in Gerrit. At the time of this writing, stable/train 72 [2] had and stable/stein had 24 [3]. Out of the latter, Vlad Gusev was the main non-Red Hat contributor.
Slight tangent but only 20 landing for train and 10 landing for stein.
If anyone is interested in becoming a stable core on Nova please feel free to reach out as we could really use more reviewers.
So my proposal is simple: I'm willing to help resolve conflicts in stable/stein backport for folks like Vlad, if it means making backports to stable/train easier. I'm confident that it would still mean an overall reduction in man-hours for backports, even if I become personally on the hook to deal with the fallout of backporting test refactors to stable/train.
Well that's good of you Artom but I don't think that should be required to land such backports on a given stable branch.
Just trying to be a good community citizen, and show that I'm open to listen to others' concerns :) (And, full disclosure, also making the bet that it'll happen so rarely that it won't affect me.)
Cheers,
Lee
[1] https://review.opendev.org/c/openstack/nova/+/791481 [2] https://review.opendev.org/q/project:openstack/nova+branch:stable/train+-age... [3] https://review.opendev.org/q/project:openstack/nova+branch:stable/stein+-age...
-- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
On Tue, Sep 14 2021 at 01:55:14 PM -0400, Artom Lifshitz <alifshit@redhat.com> wrote:
Hey Elod and Vlad (and the ML, cc'ed)
This is continuing the conversation Elod and I had on IRC. The immediate context is [1], which is a test refactor backport that in turn enables conflict-free backporting of at least two fixes.
From Red Hat's point of view, we will have to care about stable/train for *very* long time, so we'd like to do everything we can to make our lives easier, including backportings things are aren't strictly necessary (like test refactors) in order to greatly facilitate future backports, which tend to be of the "func reproducer test + actual fix" variety.
Elod made the excellent point that while this approach does make backports to train much easier to both write and review, it also "postpones" all of the manual conflict resolution work onto anyone doing stable/stein backports.
I went and gathered data. I looked at the last 6 months of backports in Gerrit. At the time of this writing, stable/train 72 [2] had and stable/stein had 24 [3]. Out of the latter, Vlad Gusev was the main non-Red Hat contributor.
So my proposal is simple: I'm willing to help resolve conflicts in stable/stein backport for folks like Vlad, if it means making backports to stable/train easier. I'm confident that it would still mean an overall reduction in man-hours for backports, even if I become personally on the hook to deal with the fallout of backporting test refactors to stable/train.
In my view there is work and risk attached to resolve a conflict during backporting a bugfix, as well as work and risk attached to backporting a test refactor instead. If the former is bigger than the latter then I would do the latter. As the latter potentially helps avoiding multiple instance of the former I can imagine that the latter is a better general approach. Based on this I can even accept non-test but production code refactors to be backported as we did for example with the libvirt device detach series. Cheers, gibi
Cheers!
[1] https://review.opendev.org/c/openstack/nova/+/791481 [2] https://review.opendev.org/q/project:openstack/nova+branch:stable/train+-age... [3] https://review.opendev.org/q/project:openstack/nova+branch:stable/stein+-age...
participants (3)
-
Artom Lifshitz
-
Balazs Gibizer
-
Lee Yarwood