Re: [openstack-dev] [Openstack-operators] LTS pragmatic example
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 >> 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 >>> 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
Re: [openstack-dev] [Openstack-operators] LTS pragmatic example
Saverio Proto wrote: > 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. Every deployer has different expectations for "stable", which is why we have a stable branch policy. Our current policy is a trade-off between being a source of important fixes ("bugfix" branch), and changing less and less as time moves on ("stable" branch). The idea behind it being, if people lived with a minor issue for so long, the behavior change creates more "instability" than keeping the minor bug in. The rules have been followed in this case -- it's a UI bug, but changing the behavior now would create unwanted churn on a "stable" branch for little gain. You seem to be interested in a policy shift toward more of a "bugfix" branch where any fix should be allowed to land, and where branch age should not be a factor. It would be interesting to assess if that is a general view. I know that distros in general are happy with more of a "stable" approach. > But merging a patch that changes a log file in Nova back to Newton was > OKAY few weeks ago. Could you provide a link to that one ? -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [Openstack-operators] LTS pragmatic example
> You seem to be interested in a policy shift toward more of a "bugfix" > branch where any fix should be allowed to land, and where branch age > should not be a factor. It would be interesting to assess if that is a > general view. I know that distros in general are happy with more of a > "stable" approach. Hello Thierry, you are right. A bugfix branch is very important for us. I cannot keep a UX bug in production, when I have a user that opens a support ticket about this. I have to avoid the second user opening the second ticket for the very same problem. If merging to a common bugfix branch is not possible, I will have to carry local patches. Please be aware that most Openstack Ubuntu packages do carry local patches in the debian/patches/ folder. I am pretty sure that this patch could land without problems in the Ubuntu packages for Newton/Horizon. > >> But merging a patch that changes a log file in Nova back to Newton was >> OKAY few weeks ago. > Could you provide a link to that one ? sure, here it is: https://review.openstack.org/#/q/If525313c63c4553abe8bea6f2bfaf75431ed18ea Thank you Saverio -- 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
Re: [openstack-dev] [Openstack-operators] LTS pragmatic example
2018-01-31 17:51 GMT+09:00 Saverio Proto : > 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 >>> 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 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 Maili
Re: [openstack-dev] [Openstack-operators] LTS pragmatic example
On 1/31/2018 2:51 AM, Saverio Proto wrote: 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 Regarding the stable policy docs, there is a note right after the support phases table saying, essentially, 'it depends': https://docs.openstack.org/project-team-guide/stable-branches.html#support-phases "It’s nevertheless allowed to backport fixes for other bugs if their safety can be easily proved. For example, documentation fixes, debug log message typo corrections, test only changes, patches that enhance test coverage, configuration file content fixes can apply to all supported branches. For those types of backports, stable maintainers will decide on case by case basis." Furthermore there is the "Appropriate fixes" section: https://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes That also goes into detail about risk vs reward here. Maybe there should be an asterisk in the support phases table so that people read the notes, or we should move the support phases table below the note so it's considered. Also, please keep in mind that the people doing stable branch maintenance upstream aren't trying to make your life hard. There is no one rule that fits all patches. The stable policy is a guideline, and if there is doubt about whether or not a patch should be accepted in stable, I consider the policy as the guideline for what the maintainers should do. -- 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
Re: [openstack-dev] [Openstack-operators] LTS pragmatic example
Hello ! thanks for accepting the patch :) It looks like the best is always to send an email and have a short discussion together, when we are not sure about a patch. thank you Cheers, 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
Re: [openstack-dev] [Openstack-operators] LTS pragmatic example
On 2/1/2018 2:56 AM, Saverio Proto wrote: Hello ! thanks for accepting the patch :) It looks like the best is always to send an email and have a short discussion together, when we are not sure about a patch. thank you Cheers, Saverio There is also the #openstack-stable IRC channel if you want to get a faster response without having to go to the mailing list. Feel free to ping me there anytime about stable patch questions. -- 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
Re: [openstack-dev] [Openstack-operators] LTS pragmatic example
On 14/11/17 22:33 +1100, Davanum Srinivas wrote: Saverio, This is still under the stable team reviews... NOT LTS. Your contacts for the Nova Stable team is ... https://review.openstack.org/#/admin/groups/540,members Let's please be clear, we need new people to help with LTS plans. Current teams can't scale, they should not have to and it's totally unfair to expect them to do so. I think you may have misunderstood Saverio's email. IIUC, what he was trying to do was provide an example in favor of the LTS branches as discussed in Sydney, rather than requesting for reviews or suggesting the stable team should do LTS. Flavio On Tue, Nov 14, 2017 at 8:02 PM, Saverio Proto wrote: Hello, here an example of a trivial patch that is important for people that do operations, and they have to troubleshoot stuff. with the old Stable Release thinking this patch would not be accepted on old stable branches. Let's see if this gets accepted back to stable/newton https://review.openstack.org/#/q/If525313c63c4553abe8bea6f2bfaf75431ed18ea Please note that a developers/operators that make the effort of fixing this in master, should do also all the cherry-pickes back. We dont have any automatic procudure for this. thank you Saverio -- @flaper87 Flavio Percoco signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [Openstack-operators] LTS pragmatic example
Flavio, Saverio, Agree, that review may be a good example of what could be done. More info below. Saverio said - "with the old Stable Release thinking this patch would not be accepted on old stable branches." My response - "Those branches are still under stable policy. That has not changed just because of an email thread or a discussion in Forum" Saverio said - "Let's see if this gets accepted back to stable/newton" My response - "The branch the review is against is still under stable policy. So things that will or will not be backported will not change" Saverio said - "Please note that a developers/operators that make the effort of fixing this in master, should do also all the cherry-pickes back. We dont have any automatic procudure for this." My response - "How the cherry-picks are done for stable branches will not change. This is a stable branch, so there is no automatic procedure for backporting" I really want folks to help with stable first, learn how things are done and then propose changes to stable branch policies and help execute them If folks want to chase LTS, then we are outlining a procedure/process that is a first step towards LTS eventually. Thanks, Dims On Wed, Nov 15, 2017 at 2:46 AM, Flavio Percoco wrote: > On 14/11/17 22:33 +1100, Davanum Srinivas wrote: >> >> Saverio, >> >> This is still under the stable team reviews... NOT LTS. >> >> Your contacts for the Nova Stable team is ... >> https://review.openstack.org/#/admin/groups/540,members >> >> Let's please be clear, we need new people to help with LTS plans. >> Current teams can't scale, they should not have to and it's totally >> unfair to expect them to do so. > > > I think you may have misunderstood Saverio's email. IIUC, what he was trying > to > do was provide an example in favor of the LTS branches as discussed in > Sydney, > rather than requesting for reviews or suggesting the stable team should do > LTS. > > Flavio > >> On Tue, Nov 14, 2017 at 8:02 PM, Saverio Proto wrote: >>> >>> Hello, >>> >>> here an example of a trivial patch that is important for people that >>> do operations, and they have to troubleshoot stuff. >>> >>> with the old Stable Release thinking this patch would not be accepted >>> on old stable branches. >>> >>> Let's see if this gets accepted back to stable/newton >>> >>> >>> https://review.openstack.org/#/q/If525313c63c4553abe8bea6f2bfaf75431ed18ea >>> >>> Please note that a developers/operators that make the effort of fixing >>> this in master, should do also all the cherry-pickes back. We dont >>> have any automatic procudure for this. >>> >>> thank you >>> >>> Saverio > > > -- > @flaper87 > Flavio Percoco -- Davanum Srinivas :: https://twitter.com/dims __ 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
Re: [openstack-dev] [Openstack-operators] LTS pragmatic example
Excerpts from Davanum Srinivas (dims)'s message of 2017-11-15 03:04:38 +1100: > Flavio, Saverio, > > Agree, that review may be a good example of what could be done. More info > below. > > Saverio said - "with the old Stable Release thinking this patch would > not be accepted on old stable branches." > My response - "Those branches are still under stable policy. That has > not changed just because of an email thread or a discussion in Forum" 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. > Saverio said - "Let's see if this gets accepted back to stable/newton" > My response - "The branch the review is against is still under stable > policy. So things that will or will not be backported will not change" > > Saverio said - "Please note that a developers/operators that make the > effort of fixing this in master, should do also all the cherry-pickes > back. We dont have any automatic procudure for this." > My response - "How the cherry-picks are done for stable branches will > not change. This is a stable branch, so there is no automatic > procedure for backporting" Do we really not have any automation for proposing a cherry-pick back through multiple branches? I know it can be done with a bunch of clicks in gerrit, but it seems like it should be possible to automate. Can someone write that script and put it into the release-tools repo? > I really want folks to help with stable first, learn how things are > done and then propose changes to stable branch policies and help > execute them > > If folks want to chase LTS, then we are outlining a procedure/process > that is a first step towards LTS eventually. > > Thanks, > Dims > > On Wed, Nov 15, 2017 at 2:46 AM, Flavio Percoco wrote: > > On 14/11/17 22:33 +1100, Davanum Srinivas wrote: > >> > >> Saverio, > >> > >> This is still under the stable team reviews... NOT LTS. > >> > >> Your contacts for the Nova Stable team is ... > >> https://review.openstack.org/#/admin/groups/540,members > >> > >> Let's please be clear, we need new people to help with LTS plans. > >> Current teams can't scale, they should not have to and it's totally > >> unfair to expect them to do so. > > > > > > I think you may have misunderstood Saverio's email. IIUC, what he was trying > > to > > do was provide an example in favor of the LTS branches as discussed in > > Sydney, > > rather than requesting for reviews or suggesting the stable team should do > > LTS. > > > > Flavio > > > >> On Tue, Nov 14, 2017 at 8:02 PM, Saverio Proto wrote: > >>> > >>> Hello, > >>> > >>> here an example of a trivial patch that is important for people that > >>> do operations, and they have to troubleshoot stuff. > >>> > >>> with the old Stable Release thinking this patch would not be accepted > >>> on old stable branches. > >>> > >>> Let's see if this gets accepted back to stable/newton > >>> > >>> > >>> https://review.openstack.org/#/q/If525313c63c4553abe8bea6f2bfaf75431ed18ea > >>> > >>> Please note that a developers/operators that make the effort of fixing > >>> this in master, should do also all the cherry-pickes back. We dont > >>> have any automatic procudure for this. > >>> > >>> thank you > >>> > >>> Saverio > > > > > > -- > > @flaper87 > > Flavio Percoco > __ 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
Re: [openstack-dev] [Openstack-operators] LTS pragmatic example
> 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
Re: [openstack-dev] [Openstack-operators] LTS pragmatic example
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 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 __ 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
Re: [openstack-dev] [Openstack-operators] LTS pragmatic example
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 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 > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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
Re: [openstack-dev] [Openstack-operators] LTS pragmatic example
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 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 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