Open Stack

Thierry Carrez <thierry at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev