> On 19 May 2016, at 13:18, Tony Breeds <[email protected]> wrote: > > On Thu, May 19, 2016 at 10:49:26AM +0200, Ihar Hrachyshka wrote: >> >>> On 19 May 2016, at 02:12, Tony Breeds <[email protected]> wrote: >>> >>> On Tue, May 17, 2016 at 01:07:48PM +0200, Ihar Hrachyshka wrote: >>>> Hi stable-maint-core and all, >>>> >>>> I would like to propose Brian for neutron specific stable team. >>> >>> +1 >>> >>> It'd be nice to see some comments on the reviews to indicate that the >>> various >>> aspects of the policy have been thought about. >>> >>> I know it gets a little repetitive but it's hard to assess the quality of >>> reviews without it :/ >> >> Meh. I am not sure we want to follow the rabbit into the deep hole. > > Fair enough. We can agree to disagree ;P
My problem with reviewing specific comments is that we never made it a requirement for nominations into other core teams. (When I was nominated to neutron-core, no one validated my specific comments; instead votes were based on general perception of my contributions.) If we think it should be a requirement for stable maintainers, we may make it explicit in our stable policies, and then we may enforce it. [Not that I agree with such a requirement...] > >> I say, people working with the person in question are in the best position to >> judge. If you don’t pay attention to neutron branches (rightfully so!), >> obviously it’s hard to assess. > > Of course. I agree with you. > >> That’s why we should have some sense of delegation in our stable team >> hierarchy (stable-maint-core doing initial sanity checks, details left up to >> project specific teams). > > You say "should" here, which confuses me a little as I thought that's exactly > what we did. Where do you feel like we should delegate, that we aren't? We do delegate. I only suggested that it’s hard for stable-maint-core to assess candidate involvement in project specific stable matters, hence we should generally trust choices made by project teams, as long as they pass basic sanity checks. Getting into too much detail, like checking candidate’s comments in gerrit, does seem like too much to me. Though basic validation that the person have a significant history of prior reviews does seem like a reasonable job for stable-maint-core though. Stable releases are still supervised by stable PTL and liaisons, and are done in gerrit, where any issues with policy violations can be discussed, and where violators may be held responsible. If stable-maint-core will have problems with some candidates, we can always revoke permissions. Ihar
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
