Thierry Carrez <thie...@openstack.org> wrote:
Carl Baldwin wrote:
- StableBranch page though requires that we don’t merge non-critical bug
fixes there: "Only critical bugfixes and security patches are acceptable”
Seems a little premature for Kilo. It is little more than 6 months old.
Some projects may want to continue backporting reasonable (even though
non-critical) fixes to older stable branches. F.e. in neutron, I think
there
is will to continue providing backports for the branch.
+1 I'd like to reiterate my support for backporting appropriate and
sensible bug fixes to Kilo.
"Stable" always had two conflicting facets: it means working well, and
it means changing less. In the first stage of stable maintenance the
focus is on "working well", with lots of backports for issues discovered
in the initial release. But after some time you caught all of the major
issues and the focus shifts to "changing less". This is what the support
phases are about, gradually shifting from one facet to another.
OK, I guess we are currently bound by stable policy [1], and without
changing the document, we cannot proceed with non-critical backports. At
this point I am not clear how huge interest from distributions to maintain
the older (N-2) branches will be.
[1]:
http://docs.openstack.org/project-team-guide/stable-branches.html#support-phases
That said, that can certainly be revisited. I suppose as long as extra
care is taken in selecting appropriate fixes for older branches, we can
get the best of both worlds.
I will talk to team members whether they feel strongly about it, and if so,
I’ll propose some policy change that would allow projects to extend the
scope of backports for older stable branches.
Note that we'll likely spin out the stable branch maintenance team into
its own project team (outside of the release management team), now that
its focus is purely on defining a common stable branch policy and making
sure it's respected across a wide range of project-specific maintenance
teams. So that new team could definitely change the common rules there
:) More on that soon.
Cheers,
--
Thierry Carrez (ttx)
__________________________________________________________________________
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
__________________________________________________________________________
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
