<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 10, 2016 at 4:57 PM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
We discussed this in our meeting[1] this week, and agreed a ML discussion<br>
to gain consensus and give folks visibility of the outcome would be a good<br>
idea.<br>
<br>
In summary, we adopted a more permissive "release branch" policy[2] for our<br>
stable/liberty branches, where feature backports would be allowed, provided<br>
they worked with liberty and didn't break backwards compatibility.<br>
<br>
The original idea was really to provide a mechanism to "catch up" where<br>
features are added e.g to liberty OpenStack components late in the cycle<br>
and TripleO requires changes to integrate with them.<br>
<br>
However, the reality has been that the permissive backport policy has been<br>
somewhat abused (IMHO) with a large number of major features being proposed<br>
for backport, and in a few cases this has broken downstream (RDO) consumers<br>
of TripleO.<br>
<br>
Thus, I would propose that from Mitaka, we revise our backport policy to<br>
simply align with the standard stable branch model observed by all<br>
projects[3].<br>
<br>
Hopefully this will allow us to retain the benefits of the stable branch<br>
process, but provide better stability for downstream consumers of these<br>
branches, and minimise confusion regarding what is a permissable backport.<br>
<br>
If we do this, only backports that can reasonably be considered<br>
"Appropriate fixes"[4] will be valid backports - in the majority of cases<br>
this will mean bugfixes only, and large features where the risk of<br>
regression is significant will not be allowed.<br>
<br>
What are peoples thoughts on this?<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace">I'm in agreement. I think this change is needed and will help set better expectations around what will be included in which release.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">If we adopt this as the new policy, then the immediate followup is to set and communicate when we'll be cutting the stable branches, so that it's understood when the features have to be done/committed. I'd suggest that we more or less completely adopt the integrated release schedule[1]. Which I believe means the week of RC1 for cutting the stable/mitaka branches, which is March 14th-18th.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">It seems to follow logically then that we'd then want to also be more aggresively aligned with other integrated release events such as the feature freeze date, Feb 29th - March 4th.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace">An alternative to strictly following the schedule, would be to say that TripleO lags the integrated release dates by some number of weeks (1 or 2 I'd think), to allow for some "catchup" time since TripleO is often consuming features from projects part of the integrated release.<br></div><div class="gmail_default" style="font-family:monospace,monospace"><br><br>[1] <a href="http://releases.openstack.org/mitaka/schedule.html">http://releases.openstack.org/mitaka/schedule.html</a></div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
<br>
Steve<br>
<br>
[1] <a href="http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-02-09-14.01.log.html" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-02-09-14.01.log.html</a><br>
[2] <a href="https://github.com/openstack/tripleo-specs/blob/master/specs/liberty/release-branch.rst" rel="noreferrer" target="_blank">https://github.com/openstack/tripleo-specs/blob/master/specs/liberty/release-branch.rst</a><br>
[3] <a href="http://docs.openstack.org/project-team-guide/stable-branches.html" rel="noreferrer" target="_blank">http://docs.openstack.org/project-team-guide/stable-branches.html</a><br>
[4] <a href="http://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes" rel="noreferrer" target="_blank">http://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">-- James Slagle<br>--</div>
</div></div>