Re: [openstack-dev] [Openstack-operators] LTS pragmatic example

2018-02-01 Thread Matt Riedemann 

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

2018-02-01 Thread Saverio Proto 
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

2018-01-31 Thread Matt Riedemann 

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

2018-01-31 Thread Akihiro Motoki 
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
>
>

Re: [openstack-dev] [Openstack-operators] LTS pragmatic example

2018-01-31 Thread Saverio Proto 
> 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 Thread Thierry Carrez 
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

2018-01-31 Thread 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.

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

2017-11-14 Thread Matt Riedemann 

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

Re: [openstack-dev] [Openstack-operators] LTS pragmatic example

2017-11-14 Thread Davanum Srinivas 
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

2017-11-14 Thread Davanum Srinivas 
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

2017-11-14 Thread Saverio Proto 
> 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

2017-11-14 Thread Doug Hellmann 
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

2017-11-14 Thread Davanum Srinivas 
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

2017-11-14 Thread Flavio Percoco 

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