[openstack-dev] [Openstack-operators] LTS pragmatic example
mriedemos at gmail.com
Wed Nov 15 02:37:13 UTC 2017
On 11/14/2017 10:58 AM, Davanum Srinivas wrote:
> Let's focus our energy on the etherpad please
> On Wed, Nov 15, 2017 at 3:35 AM, Davanum Srinivas <davanum at gmail.com> wrote:
>> Please see this :
>> https://docs.openstack.org/project-team-guide/stable-branches.html for
>> current policies.
>> On Wed, Nov 15, 2017 at 3:33 AM, Saverio Proto <saverio.proto at switch.ch> wrote:
>>>> Which stable policy does that patch violate? It's clearly a bug
>>>> because the wrong information is being logged. I suppose it goes
>>>> against the string freeze rule? Except that we've stopped translating
>>>> log messages so maybe we don't need to worry about that in this case,
>>>> since it isn't an exception.
>>> Well, I also would like to understand more about stable policy violations.
>>> When I proposed such patches in the past for the release N-2 I have
>>> always got the answer: it is not a security issue so it will not be merged.
>>> This is a good example of how things have been working so far:
>>> This cinder patch was merged in master. It was then merged in Mitaka.
>>> But it was not merged in Liberty just because "only security fixes" were
>>> allowed at that point.
>>> You can read that in the comments:
>>> Is this kind of things going to change after the discussion in Sydney ?
>>> The discussion is not enough ? what we need to get done then ?
>>> thank you
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> Davanum Srinivas :: https://twitter.com/dims
Heh, I'm reading this thread after approving all of those patches.
The answer as to whether it's appropriate or not, is "it depends".
Depends on the patch, depends on the age of the branch, etc.
In this case, newton is in phase 3 so normally it's only security or
critical fixes allowed, but in this case it's so trivial and so
obviously wrong that I was OK with approving it just to get it in before
we end of life the branch.
So, it depends. And because it depends, that's also why we don't
automate the backport of every fix made on master. Because guess what,
we also backport "fixes" that introduce regressions, and when you do
that to n-1 (Pike at this point) then you still have a lot of time to
detect that and fix it upstream, but regressing things on the oldest
branch leaves very little time to (1) have it detected and (2) get it
fixed before end of life.
More information about the OpenStack-dev