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.
--
Thanks,
Matt
__________________________________________________________________________
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
