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. 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
