<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Nov 16, 2017 8:15 AM, "Flavio Percoco" <<a href="mailto:flavio@redhat.com">flavio@redhat.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On 15/11/17 12:17 -0500, Doug Hellmann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It has been mentioned a couple of times in tangents to existing<br>
discussions, and is listed on the etherpad, but I think it's worth<br>
having a thread to discuss what affect long-lived branches will<br>
have on the way we manage existing stable branches.<br>
<br>
The point I've raised before is that we don't want to land patches<br>
in a long-lived branch that aren't candidates for younger stable<br>
branches. That avoids a situation where a patch is available in a<br>
long-lived branch, then skips a stable branch (or two), and is again<br>
available in the master branch so that users have it, then are broken if<br>
they upgrade to one of those stable branches, then are fixed by<br>
upgrading to the version on master.<br>
<br>
I think that means we want the long-lived branches to continue the<br>
policy for the final phase of the stable branches. I'm not at all sure<br>
that conclusion meshes with anyone's idea of what those long-lived<br>
branches should be for, though.<br>
<br>
Is this conclusion a surprise to anyone? Would a long-lived branch<br>
with a strict policy for landing patches be useful? What sorts of<br>
patches would anyone consuming those branches expect to receive?<br>
</blockquote>
<br></div>
I think it does come as a surprise to some. In my notes from the session I have<br>
that one of the reasons people want these branches is because there are patches<br>
for old versions of the software that can't be backported to the existing table<br>
branches and that are also being carried around in downstream forks.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">I think there is a sizeable continent of folks that would like to see a policy that's a little less restrictive. </div><div dir="auto"><br></div><div dir="auto">-Erik</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I agree, however, that the ideal scenario is to have all these patches merged in<br>
the stable branches before they land in the long-lived ones. We have to be open<br>
to exceptions, though, as some of the bug fixes might not be aplicable in newer<br>
branches.<br>
<br>
Flavio<br>
<br>
--<br>
@flaper87<font color="#888888"><br>
Flavio Percoco<br>
</font><br>______________________________<wbr>_________________<br>
openstack-sigs mailing list<br>
<a href="mailto:openstack-sigs@lists.openstack.org">openstack-sigs@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-sigs</a><br>
<br></blockquote></div><br></div></div></div>