[nova] Backporting test refactors to stable/train
alifshit at redhat.com
Tue Sep 14 20:06:15 UTC 2021
On Tue., Sep. 14, 2021, 15:57 Lee Yarwood, <lyarwood at 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 , 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
Maybe, but at least in some cases it's still possible, like my  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:
> 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  had and
> > stable/stein had 24 . 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.)
> >  https://review.opendev.org/c/openstack/nova/+/791481
> > 
> > 
> Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openstack-discuss