2018-01-31 17:51 GMT+09:00 Saverio Proto <saverio.pr...@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 <dava...@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.pr...@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-requ...@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.pr...@switch.ch, http://www.switch.ch > > http://www.switch.ch/stories > > __________________________________________________________________________ > 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