Open Stack

2018-01-31 17:51 GMT+09:00 Saverio Proto <saverio.proto at switch.ch>:
> Hello all,
>
> I am again proposing a change due to operations experience. I am
> proposing a clean and simple cherry-pick to Ocata.
>
> "it depends" works pretty bad as policy for accepting patches.
>
> Now I really dont understand what is the issue with the Stable Policy
> and this patch:
>
> https://review.openstack.org/#/c/539439/
>
> This is a UX problem. Horizon is giving the wrong information to the user.
>
> I got this answer:
> Ocata is the second phase of stable branches [1]. Only critical bugfixes
> and security patches are acceptable. I don't think it belongs to the
> category.
>

It is really understandable.

I am the person who put -1 on the horizon backport raised here. In
this specific case, the proposed backport does not import a new
confusion and it will provide a correct error message for a specific
case, so when I put -1 I struggled whether I put +2 or -1. It is
half-and-half. I am okay to remove my -1.

On the other hand, it is important to share some common criteria among
the stable reviewers.
different reviewers can apply different criteria. it is not productive
to define a project specific policy which is a bit different from the
common stable branch policy.
I would like to see some updated stable policy in near future as
output of LTS discussions.

Akihiro

> But merging a patch that changes a log file in Nova back to Newton was
> OKAY few weeks ago.
>
> I will not be able to be in person at the PTG, but please talk about
> this. People just give up upstreaming stuff like this.
>
> thank you
>
> Saverio
>
>
> On 15.11.17 03:37, Matt Riedemann wrote:
>> On 11/14/2017 10:58 AM, Davanum Srinivas wrote:
>>> Let's focus our energy on the etherpad please
>>>
>>> https://etherpad.openstack.org/p/LTS-proposal
>>>
>>> On Wed, Nov 15, 2017 at 3:35 AM, Davanum Srinivas <davanum at gmail.com>
>>> wrote:
>>>> Saverio,
>>>>
>>>> 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:
>>>>>
>>>>> https://review.openstack.org/#/q/677eb1c4160c08cfce2900495741f0ea15f566fa
>>>>>
>>>>>
>>>>> 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:
>>>>> https://review.openstack.org/#/c/306610/
>>>>>
>>>>> 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
>>>>>
>>>>> Saverio
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>>
>>>>> 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
>>>>
>>>>
>>>>
>>>> --
>>>> 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.
>>
>
>
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.proto at switch.ch, http://www.switch.ch
>
> http://www.switch.ch/stories
>
> __________________________________________________________________________
> 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