Open Stack

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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-sigs/attachments/20171116/da8ad5aa/attachment.sig>