Open Stack

-----Original Message-----
From: Thomas Herve <therve at redhat.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at lists.openstack.org>
Date: February 17, 2017 at 09:40:23
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at 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