On 11/14/2017 02:10 PM, Doug Hellmann wrote:
Excerpts from Chris Friesen's message of 2017-11-14 14:01:58 -0600:
On 11/14/2017 01:28 PM, Dmitry Tantsur wrote:
The quality of backported fixes is expected to be a direct (and only?)
interest of those new teams of new cores, coming from users and operators and
vendors.
I'm not assuming bad intentions, not at all. But there is a lot of involved in a
decision whether to make a backport or not. Will these people be able to
evaluate a risk of each patch? Do they have enough context on how that release
was implemented and what can break? Do they understand why feature backports are
bad? Why they should not skip (supported) releases when backporting?
I know a lot of very reasonable people who do not understand the things above
really well.
I would hope that the core team for upstream LTS would be the (hopefully
experienced) people doing the downstream work that already happens within the
various distros.
Chris
Presumably those are the same people we've been trying to convince
to work on the existing stable branches for the last 5 years. What
makes these extended branches more appealing to those people than
the existing branches? Is it the reduced requirements on maintaining
test jobs? Or maybe some other policy change that could be applied
to the stable branches?
For what it's worth, we often lag more than 6 months behind master and so some
of the things we backport wouldn't be allowed by the existing stable branch
support phases. (ie aren't "critical" or security patches.)
Chris
__________________________________________________________________________
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
