Excerpts from Chris Friesen's message of 2017-11-14 15:50:08 -0600: > 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 >
We should include a review of some of those policies as part of this discussion. It would seem very odd to have a fix land in master, not make it into the stable branches, and then show up in a branch following the LTS policy. Doug __________________________________________________________________________ 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
