On Wed, 2016-02-10 at 15:57 +0000, Steven Hardy wrote: > Hi all, > > We discussed this in our meeting[1] this week, and agreed a ML > discussion > to gain consensus and give folks visibility of the outcome would be a > good > idea. > > In summary, we adopted a more permissive "release branch" policy[2] > for our > stable/liberty branches, where feature backports would be allowed, > provided > they worked with liberty and didn't break backwards compatibility. > > The original idea was really to provide a mechanism to "catch up" > where > features are added e.g to liberty OpenStack components late in the > cycle > and TripleO requires changes to integrate with them. > > However, the reality has been that the permissive backport policy has > been > somewhat abused (IMHO) with a large number of major features being > proposed > for backport, and in a few cases this has broken downstream (RDO) > consumers > of TripleO. > > Thus, I would propose that from Mitaka, we revise our backport policy > to > simply align with the standard stable branch model observed by all > projects[3]. > > Hopefully this will allow us to retain the benefits of the stable > branch > process, but provide better stability for downstream consumers of > these > branches, and minimise confusion regarding what is a permissable > backport. > > If we do this, only backports that can reasonably be considered > "Appropriate fixes"[4] will be valid backports - in the majority of > cases > this will mean bugfixes only, and large features where the risk of > regression is significant will not be allowed. > > What are peoples thoughts on this?
Yes. The relaxed feature backporting for Mitaka has been quite abused. Our upstream has been in a "optimized for backport" mode for some time now. So much so that I think you could think of Mitaka has being sort of a featureless release at this point because aside from a few exceptions to the undercloud itself we haven't added that many Mitaka features that weren't also backported to Liberty. ++ for the idea of getting back to a normal upstream release/branching models. Dan > > Thanks, > > Steve > > [1] http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016 > -02-09-14.01.log.html > [2] https://github.com/openstack/tripleo-specs/blob/master/specs/libe > rty/release-branch.rst > [3] http://docs.openstack.org/project-team-guide/stable-branches.html > [4] http://docs.openstack.org/project-team-guide/stable-branches.html > #appropriate-fixes > > _____________________________________________________________________ > _____ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs > cribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
