Isn't #2 the right approach?
Even if it might be more 'work' I personally would prefer #2 and do it
right (and make it easier to do the right thing in the future via
scripts, automation, other) vs. the other mentioned approaches.
If we were consuming, say a 3rd party library and that 3rd party library
had/has a security issue, isn't the above the same thing that you would
have to do?
My 2 cents.
Matt Riedemann wrote:
Here's why:
https://review.openstack.org/#/c/220622/
That's marked as fixing an OSSA which means we'll have to backport the
fix in nova but it depends on a change to strutils.mask_password in
oslo.utils, which required a release and a minimum version bump in
global-requirements.
To backport the change in nova, we either have to:
1. Copy mask_password out of oslo.utils and add it to nova in the
backport or,
2. Backport the oslo.utils change to a stable branch, release it as a
patch release, bump minimum required version in stable g-r and then
backport the nova change and depend on the backported oslo.utils stable
release - which also makes it a dependent library version bump for any
packagers/distros that have already frozen libraries for their stable
releases, which is kind of not fun.
So I'm thinking this is one of those things that should ultimately live
in oslo-incubator so it can live in the respective projects. If
mask_password were in oslo-incubator, we'd have just fixed and
backported it there and then synced to nova on master and stable
branches, no dependent library version bumps required.
Plus I miss the good old days of reviewing oslo-incubator
syncs...(joking of course).
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
