Open Stack

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