Open Stack

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


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.

Flavio

--
@flaper87
Flavio Percoco

_______________________________________________
openstack-sigs mailing list
openstack-sigs at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-sigs/attachments/20171116/9aa07a48/attachment.html>