Open Stack

Ihar,

Thanks for the nomination, I'll just chime-in below.

On 05/19/2016 03:13 PM, Ihar Hrachyshka wrote:
>
>> On 19 May 2016, at 13:18, Tony Breeds <tony at bakeyournoodle.com> wrote:
>>
>> On Thu, May 19, 2016 at 10:49:26AM +0200, Ihar Hrachyshka wrote:
>>>
>>>> On 19 May 2016, at 02:12, Tony Breeds <tony at bakeyournoodle.com> 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'll admit I typically haven't been judging stable backports from a policy 
perspective, I'm typically looking at them from the other end - now that we 
fixed this in master, is this broken in stable/foo and should it be backported? 
  And how far?  And does it make sense?  Basically, changing from a reactive to 
a proactive model.

I know most of the stable rules, and when I don't know what to do I usually just 
ask Ihar ;)

>>> 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.

I'm part of the DVR sub-team in Neutron, so most of my focus is there, and it's 
been a pretty hot spot in the stable releases as people start to deploy it more. 
  I agreed to the nomination so I could be delegated in that little corner and 
expand from there, much as I did with upstream Neutron.  My goal is to increase 
the speed at which the downstream users (distros) can consume the stable 
branches and get fixes to their customers.

-Brian