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

Steven Hardy shardy at redhat.com
Mon Feb 20 14:37:45 UTC 2017

On Fri, Feb 17, 2017 at 10:07:38PM +0530, Rabi Mishra wrote:
>    On Fri, Feb 17, 2017 at 8:44 PM, Matt Riedemann <mriedemos at gmail.com>
>    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-request at 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.



More information about the OpenStack-dev mailing list