Open Stack

Excerpts from Erik McCormick's message of 2017-11-16 09:08:38 -0500:
> > On Nov 16, 2017 8:15 AM, "Flavio Percoco" <flavio at redhat.com> wrote:
> > 
> > On 15/11/17 12:17 -0500, Doug Hellmann wrote:
> > 
> > > It has been mentioned a couple of times in tangents to existing
> > > discussions, and is listed on the etherpad, but I think it's worth
> > > having a thread to discuss what affect long-lived branches will
> > > have on the way we manage existing stable branches.
> > >
> > > The point I've raised before is that we don't want to land patches
> > > in a long-lived branch that aren't candidates for younger stable
> > > branches. That avoids a situation where a patch is available in a
> > > long-lived branch, then skips a stable branch (or two), and is again
> > > available in the master branch so that users have it, then are broken if
> > > they upgrade to one of those stable branches, then are fixed by
> > > upgrading to the version on master.
> > >
> > > I think that means we want the long-lived branches to continue the
> > > policy for the final phase of the stable branches. I'm not at all sure
> > > that conclusion meshes with anyone's idea of what those long-lived
> > > branches should be for, though.
> > >
> > > Is this conclusion a surprise to anyone? Would a long-lived branch
> > > with a strict policy for landing patches be useful? What sorts of
> > > patches would anyone consuming those branches expect to receive?
> > >
> > 
> > I think it does come as a surprise to some. In my notes from the session I
> > have
> > that one of the reasons people want these branches is because there are
> > patches
> > for old versions of the software that can't be backported to the existing
> > table
> > branches and that are also being carried around in downstream forks.
> > 
> > 
> One reason for this is some companies don't even manage to get onto a
> version before it's gone from stable. If they find a bug and make a patch,
> there is currently nowhere to land it.
> 
> I think there is a sizeable continent of folks that would like to see a
> policy that's a little less restrictive.
> 
> -Erik

If we assume that no branches are going to be deleted so that it
would be possible to take a patch from master all the way back to
an long-lived branch, would we be able to live with a policy that
required it? What if there is a gap between the last branch under
the stable policy and the long-lived branch where the user actually
needs the patch?

What adjustments to the stable policy would we need? Should we
completely drop our current definition of phases and allow all bug
fixes?

Are people expecting to be able to backport features to long-lived
branches?

> > 
> > 
> > I agree, however, that the ideal scenario is to have all these patches
> > merged in
> > the stable branches before they land in the long-lived ones. We have to be
> > open
> > to exceptions, though, as some of the bug fixes might not be aplicable in
> > newer
> > branches.

Sure, I think our current policy allows for that already but if not we
should extend it independently of any other changes.


Doug