Re: [openstack-dev] [stable][heat] Heat stable-maint additions

[Thierry Carrez]

Steven Hardy wrote:
> I agree - those nominated by Zane are all highly experienced reviewers and
> as ex-PTLs are well aware of the constraints around stable backports and
> stable release management.
> 
> I do agree the requirements around reviews for stable branches are very
> different, but I think we need to assume good faith here and accept we have
> a bottleneck which can be best fixed by adding some folks we *know* are
> capable of exercising sound judgement to the stable-maint team for heat.
> 
> I respect the arguments made by the stable-maint core folks, and I think we
> all understand the reason for these concerns, but ultimately unless folks
> outside the heat core team are offering to help with reviews directly, I
> think it's a little unreasonable to block the addition of these reviewers,
> given they've been proposed by the current stable liason who I think is in
> the best position to judge the suitability of candidates.

That sounds reasonable to me. I think you should be able to get it
settled with tonyb over beer sometimes this week :)

-- 
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] [stable][heat] Heat stable-maint additions

[Steven Hardy]

On Fri, Feb 17, 2017 at 10:07:38PM +0530, Rabi Mishra wrote:
>On Fri, Feb 17, 2017 at 8:44 PM, Matt Riedemann 
>wrote:
> 
>  On 2/15/2017 12:40 PM, Zane Bitter wrote:
> 
>Traditionally Heat has given current and former PTLs of the project +2
>rights on stable branches for as long as they remain core reviewers.
>Usually I've done that by adding them to the heat-release group.
> 
>At some point the system changed so that the review rights for these
>branches are no longer under the team's control (instead, the
>stable-maint core team is in charge), and as a result at least the
>current PTL (Rico Lin) and the previous PTL (Rabi Mishra), and
>possibly
>others (Thomas Herve, Sergey Kraynev), haven't been added to the
>group.
>That's slowing down getting backports merged, amongst other things.
> 
>I'd like to request that we update the membership to be the same as
>https://review.openstack.org/#/admin/groups/152,members
> 
>Rabi Mishra
>Rico Lin
>Sergey Kraynev
>Steve Baker
>Steven Hardy
>Thomas Herve
>Zane Bitter
> 
>I also wonder if the stable-maint team would consider allowing the
>Heat
>team to manage the group membership again if we commit to the criteria
>above (all current/former PTLs who are also core reviewers) by just
>adding that group as a member of heat-stable-maint?
> 
>thanks,
>Zane.
> 
>
> __
>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
> 
>  Reviewing patches on stable branches have different guidelines,
>  expressed here [1]. In the past when this comes up I've asked if the
>  people being asked to be added to the stable team for a project have
>  actually been doing reviews on the stable branches to show they are
>  following the guidelines, and at times when this has come up the people
>  proposed (usually PTLs) haven't, so I've declined at that time until
>  they start actually doing reviews and can show they are following the
>  guidelines.
> 
>  There are reviewstats tools for seeing the stable review numbers for
>  Heat, I haven't run that though to check against those proposed above,
>  but it's probably something I'd do first before just adding a bunch of
>  people.
> 
>Would it not be appropriate to trust the stable cross-project liaison for
>heat when he nominates stable cores? Having been the PTL for Ocata and one
>who struggled to get the backports on time for a stable release as
>planned, I don't recall seeing many reviews from stable maintenance core
>team for them to be able to judge the quality of reviews. So I don't think
>it's fair to decide eligibility only based on the review numbers and
>stats.

I agree - those nominated by Zane are all highly experienced reviewers and
as ex-PTLs are well aware of the constraints around stable backports and
stable release management.

I do agree the requirements around reviews for stable branches are very
different, but I think we need to assume good faith here and accept we have
a bottleneck which can be best fixed by adding some folks we *know* are
capable of exercising sound judgement to the stable-maint team for heat.

I respect the arguments made by the stable-maint core folks, and I think we
all understand the reason for these concerns, but ultimately unless folks
outside the heat core team are offering to help with reviews directly, I
think it's a little unreasonable to block the addition of these reviewers,
given they've been proposed by the current stable liason who I think is in
the best position to judge the suitability of candidates.

Thanks,

Steve

__
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] [stable][heat] Heat stable-maint additions

[Zane Bitter]

On 18/02/17 03:24, Thierry Carrez wrote:

Thomas Herve wrote:

[...]
At any rate, it's a matter of trust, a subject that comes from time to
time, and it's fairly divisive. In this case though, I find it ironic
that I can approve whatever garbage I want on master, it can make its
way into a release, but if I want a bugfix backported into another
branch, someone else has to supervise me.


Originally the lock was there to make sure that people with stable/*
rights were aware of the stable policy (in particular which changes are
backportable depending on the support phase). Rules to apply in stable
reviews are *completely* different from the rules to apply on master
reviews - so being trusted for master doesn't magically make you aware
of review rules for stable.


Yes, this is reasonable. FWIW I'm 100% confident that all of the ex-PTLs 
are familiar with the stable branch policy (I am the stable-branch 
liaison for Heat).



That said, I thought that we now defaulted to trusting the local stable
liaison to ensure that the policy was well-known and directly add people
to the group... (with stable-maint being able to remove people if
needed, ask for forgiveness rather than permission, etc.)


This seems like an appropriate policy to me. I would be happy to see it 
adopted if it hasn't been already.



I guess that's something we could discuss in the Stable team room
(Monday morning) at the PTG for those who will be around then.


I might stop by :)

cheers,
Zane.


__
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] [stable][heat] Heat stable-maint additions

[Thierry Carrez]

Thomas Herve wrote:
> [...]
> At any rate, it's a matter of trust, a subject that comes from time to
> time, and it's fairly divisive. In this case though, I find it ironic
> that I can approve whatever garbage I want on master, it can make its
> way into a release, but if I want a bugfix backported into another
> branch, someone else has to supervise me.

Originally the lock was there to make sure that people with stable/*
rights were aware of the stable policy (in particular which changes are
backportable depending on the support phase). Rules to apply in stable
reviews are *completely* different from the rules to apply on master
reviews - so being trusted for master doesn't magically make you aware
of review rules for stable.

That said, I thought that we now defaulted to trusting the local stable
liaison to ensure that the policy was well-known and directly add people
to the group... (with stable-maint being able to remove people if
needed, ask for forgiveness rather than permission, etc.)

I guess that's something we could discuss in the Stable team room
(Monday morning) at the PTG for those who will be around then.

-- 
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] [stable][heat] Heat stable-maint additions

[Thomas Herve]

On Fri, Feb 17, 2017 at 5:48 PM, Ian Cordasco  wrote:
> -Original Message-
> From: Thomas Herve 
[snip]
>> Respecting the guidelines is totally fair, but review stats won't tell
>> you much, at least in my case: I barely do any stable reviews because
>> I don't have approve rights. In the case of Heat, 90% of the backports
>> are without conflicts, so stable reviews are just about verifying the
>> guidelines and that the patch matches what's in master.
>>
>> But, I've been working on Heat for 4 years, I made about 1400 reviews
>> on it, and I've been PTL. And the same for the other people that Zane
>> mentioned. I feel we should be trusted on stable branches.
>
> That seems like a very poor excuse - "I can't approve so I don't
> review". I'm a stable maintenance core because I was reviewing stable
> branch changes first. I had a good track record, and both the existing
> Glance stable maint core reviewers and the global team agreed I had
> displayed sound judgment for those.

It's not an excuse, I'm explaining why I don't do many stable reviews.
My time is valuable, and I don't do all the reviews that I could on
master already. I'd rather spend review time where I can move the
needle, instead on patches where ultimately that won't matter. If I
see a stable patch which doesn't make sense, I'll comment, but it's
very rare. On others, if that looks fine I don't do anything. Because
most contributors (on Heat at least) already made the effort to think
whether their change was backport worthy. And I don't chase stats.

> Without being able to assess the quality of your reviews, how should
> anyone else trust you with the stability of those branches?

You can assess the quality of my reviews on master. I don't see how
stable is so different. We can't break APIs, we can't change the DB
randomly, we can't break compatibility. The pain points (dependencies,
config options, features) are most of the time easy to spot.

(Also, Matt mentioned review stats. I could have 200 stable +1, that
would maybe look nice on paper, but not prove anything, if there is
anything to prove).

>> > There are reviewstats tools for seeing the stable review numbers for Heat, 
>> > I
>> > haven't run that though to check against those proposed above, but it's
>> > probably something I'd do first before just adding a bunch of people.
>>
>> I appreciate your guidance and input, but shouldn't we decide our
>> stable maintainers, the same way we decide cores? The current list
>> contains at least one person that doesn't contribute anymore, so it's
>> not like it's super curated.
>
> This is how every other service team works (Nova, Keystone, Glance,
> etc.). Just because the global stable maint team hasn't removed an
> inactive person doesn't invalidate their assessment of potential core
> reviewers.

Saying that how other work is not a fantastic argument. We'd need to
know if that actually works for them.

At any rate, it's a matter of trust, a subject that comes from time to
time, and it's fairly divisive. In this case though, I find it ironic
that I can approve whatever garbage I want on master, it can make its
way into a release, but if I want a bugfix backported into another
branch, someone else has to supervise me.

-- 
Thomas

__
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] [stable][heat] Heat stable-maint additions

[Ian Cordasco]

-Original Message-
From: Thomas Herve <the...@redhat.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: February 17, 2017 at 09:40:23
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [stable][heat] Heat stable-maint additions

> On Fri, Feb 17, 2017 at 4:14 PM, Matt Riedemann wrote:
> > On 2/15/2017 12:40 PM, Zane Bitter wrote:
> >>
> >> Traditionally Heat has given current and former PTLs of the project +2
> >> rights on stable branches for as long as they remain core reviewers.
> >> Usually I've done that by adding them to the heat-release group.
> >>
> >> At some point the system changed so that the review rights for these
> >> branches are no longer under the team's control (instead, the
> >> stable-maint core team is in charge), and as a result at least the
> >> current PTL (Rico Lin) and the previous PTL (Rabi Mishra), and possibly
> >> others (Thomas Herve, Sergey Kraynev), haven't been added to the group.
> >> That's slowing down getting backports merged, amongst other things.
> >>
> >> I'd like to request that we update the membership to be the same as
> >> https://review.openstack.org/#/admin/groups/152,members
> >>
> >> Rabi Mishra
> >> Rico Lin
> >> Sergey Kraynev
> >> Steve Baker
> >> Steven Hardy
> >> Thomas Herve
> >> Zane Bitter
> >>
> >> I also wonder if the stable-maint team would consider allowing the Heat
> >> team to manage the group membership again if we commit to the criteria
> >> above (all current/former PTLs who are also core reviewers) by just
> >> adding that group as a member of heat-stable-maint?
> >>
> >> thanks,
> >> Zane.
> >>
> >
> > Reviewing patches on stable branches have different guidelines, expressed
> > here [1]. In the past when this comes up I've asked if the people being
> > asked to be added to the stable team for a project have actually been doing
> > reviews on the stable branches to show they are following the guidelines,
> > and at times when this has come up the people proposed (usually PTLs)
> > haven't, so I've declined at that time until they start actually doing
> > reviews and can show they are following the guidelines.
>
> Respecting the guidelines is totally fair, but review stats won't tell
> you much, at least in my case: I barely do any stable reviews because
> I don't have approve rights. In the case of Heat, 90% of the backports
> are without conflicts, so stable reviews are just about verifying the
> guidelines and that the patch matches what's in master.
>
> But, I've been working on Heat for 4 years, I made about 1400 reviews
> on it, and I've been PTL. And the same for the other people that Zane
> mentioned. I feel we should be trusted on stable branches.

That seems like a very poor excuse - "I can't approve so I don't
review". I'm a stable maintenance core because I was reviewing stable
branch changes first. I had a good track record, and both the existing
Glance stable maint core reviewers and the global team agreed I had
displayed sound judgment for those.

Without being able to assess the quality of your reviews, how should
anyone else trust you with the stability of those branches?

> > There are reviewstats tools for seeing the stable review numbers for Heat, I
> > haven't run that though to check against those proposed above, but it's
> > probably something I'd do first before just adding a bunch of people.
>
> I appreciate your guidance and input, but shouldn't we decide our
> stable maintainers, the same way we decide cores? The current list
> contains at least one person that doesn't contribute anymore, so it's
> not like it's super curated.

This is how every other service team works (Nova, Keystone, Glance,
etc.). Just because the global stable maint team hasn't removed an
inactive person doesn't invalidate their assessment of potential core
reviewers.

--
Ian Cordasco

__
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] [stable][heat] Heat stable-maint additions

[Rabi Mishra]

On Fri, Feb 17, 2017 at 8:44 PM, Matt Riedemann  wrote:

> On 2/15/2017 12:40 PM, Zane Bitter wrote:
>
>> Traditionally Heat has given current and former PTLs of the project +2
>> rights on stable branches for as long as they remain core reviewers.
>> Usually I've done that by adding them to the heat-release group.
>>
>> At some point the system changed so that the review rights for these
>> branches are no longer under the team's control (instead, the
>> stable-maint core team is in charge), and as a result at least the
>> current PTL (Rico Lin) and the previous PTL (Rabi Mishra), and possibly
>> others (Thomas Herve, Sergey Kraynev), haven't been added to the group.
>> That's slowing down getting backports merged, amongst other things.
>>
>> I'd like to request that we update the membership to be the same as
>> https://review.openstack.org/#/admin/groups/152,members
>>
>> Rabi Mishra
>> Rico Lin
>> Sergey Kraynev
>> Steve Baker
>> Steven Hardy
>> Thomas Herve
>> Zane Bitter
>>
>> I also wonder if the stable-maint team would consider allowing the Heat
>> team to manage the group membership again if we commit to the criteria
>> above (all current/former PTLs who are also core reviewers) by just
>> adding that group as a member of heat-stable-maint?
>>
>> thanks,
>> Zane.
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> Reviewing patches on stable branches have different guidelines, expressed
> here [1]. In the past when this comes up I've asked if the people being
> asked to be added to the stable team for a project have actually been doing
> reviews on the stable branches to show they are following the guidelines,
> and at times when this has come up the people proposed (usually PTLs)
> haven't, so I've declined at that time until they start actually doing
> reviews and can show they are following the guidelines.
>
> There are reviewstats tools for seeing the stable review numbers for Heat,
> I haven't run that though to check against those proposed above, but it's
> probably something I'd do first before just adding a bunch of people.
>

Would it not be appropriate to trust the stable cross-project liaison for
heat when he nominates stable cores? Having been the PTL for Ocata and one
who struggled to get the backports on time for a stable release as planned,
I don't recall seeing many reviews from stable maintenance core team for
them to be able to judge the quality of reviews. So I don't think it's fair
to decide eligibility only based on the review numbers and stats.


> [1] https://docs.openstack.org/project-team-guide/stable-branches.html
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> 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
>

-- 
Regards,
Rabi Mishra
__
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] [stable][heat] Heat stable-maint additions

[Thomas Herve]

On Fri, Feb 17, 2017 at 4:14 PM, Matt Riedemann  wrote:
> On 2/15/2017 12:40 PM, Zane Bitter wrote:
>>
>> Traditionally Heat has given current and former PTLs of the project +2
>> rights on stable branches for as long as they remain core reviewers.
>> Usually I've done that by adding them to the heat-release group.
>>
>> At some point the system changed so that the review rights for these
>> branches are no longer under the team's control (instead, the
>> stable-maint core team is in charge), and as a result at least the
>> current PTL (Rico Lin) and the previous PTL (Rabi Mishra), and possibly
>> others (Thomas Herve, Sergey Kraynev), haven't been added to the group.
>> That's slowing down getting backports merged, amongst other things.
>>
>> I'd like to request that we update the membership to be the same as
>> https://review.openstack.org/#/admin/groups/152,members
>>
>> Rabi Mishra
>> Rico Lin
>> Sergey Kraynev
>> Steve Baker
>> Steven Hardy
>> Thomas Herve
>> Zane Bitter
>>
>> I also wonder if the stable-maint team would consider allowing the Heat
>> team to manage the group membership again if we commit to the criteria
>> above (all current/former PTLs who are also core reviewers) by just
>> adding that group as a member of heat-stable-maint?
>>
>> thanks,
>> Zane.
>>
>
> Reviewing patches on stable branches have different guidelines, expressed
> here [1]. In the past when this comes up I've asked if the people being
> asked to be added to the stable team for a project have actually been doing
> reviews on the stable branches to show they are following the guidelines,
> and at times when this has come up the people proposed (usually PTLs)
> haven't, so I've declined at that time until they start actually doing
> reviews and can show they are following the guidelines.

Respecting the guidelines is totally fair, but review stats won't tell
you much, at least in my case: I barely do any stable reviews because
I don't have approve rights. In the case of Heat, 90% of the backports
are without conflicts, so stable reviews are just about verifying the
guidelines and that the patch matches what's in master.

But, I've been working on Heat for 4 years, I made about 1400 reviews
on it, and I've been PTL. And the same for the other people that Zane
mentioned. I feel we should be trusted on stable branches.

> There are reviewstats tools for seeing the stable review numbers for Heat, I
> haven't run that though to check against those proposed above, but it's
> probably something I'd do first before just adding a bunch of people.

I appreciate your guidance and input, but shouldn't we decide our
stable maintainers, the same way we decide cores? The current list
contains at least one person that doesn't contribute anymore, so it's
not like it's super curated.

-- 
Thomas

__
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] [stable][heat] Heat stable-maint additions

[Matt Riedemann]

On 2/15/2017 12:40 PM, Zane Bitter wrote:

Traditionally Heat has given current and former PTLs of the project +2
rights on stable branches for as long as they remain core reviewers.
Usually I've done that by adding them to the heat-release group.

At some point the system changed so that the review rights for these
branches are no longer under the team's control (instead, the
stable-maint core team is in charge), and as a result at least the
current PTL (Rico Lin) and the previous PTL (Rabi Mishra), and possibly
others (Thomas Herve, Sergey Kraynev), haven't been added to the group.
That's slowing down getting backports merged, amongst other things.

I'd like to request that we update the membership to be the same as
https://review.openstack.org/#/admin/groups/152,members

Rabi Mishra
Rico Lin
Sergey Kraynev
Steve Baker
Steven Hardy
Thomas Herve
Zane Bitter

I also wonder if the stable-maint team would consider allowing the Heat
team to manage the group membership again if we commit to the criteria
above (all current/former PTLs who are also core reviewers) by just
adding that group as a member of heat-stable-maint?

thanks,
Zane.

__
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


Reviewing patches on stable branches have different guidelines, 
expressed here [1]. In the past when this comes up I've asked if the 
people being asked to be added to the stable team for a project have 
actually been doing reviews on the stable branches to show they are 
following the guidelines, and at times when this has come up the people 
proposed (usually PTLs) haven't, so I've declined at that time until 
they start actually doing reviews and can show they are following the 
guidelines.


There are reviewstats tools for seeing the stable review numbers for 
Heat, I haven't run that though to check against those proposed above, 
but it's probably something I'd do first before just adding a bunch of 
people.


[1] https://docs.openstack.org/project-team-guide/stable-branches.html

--

Thanks,

Matt Riedemann

__
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