Open Stack

On 11/8/2016 11:39 AM, Dan Smith wrote:
>> I do imagine, however, that most folks who have been working
>> on nova for long enough have a list of domain experts in their heads
>> already. Would actually putting that on paper really hurt?
>
> You mean like this?
>
> https://wiki.openstack.org/wiki/Nova#Developer_Contacts
>
> Those are pretty much the people I look to have sign off on a thing I'm
> not completely familiar with before approving something. I'm sure it
> could use some updating, of course.
>
> This is linked from the MAINTAINERS file in our tree, by the way.
>
> --Dan
>
> __________________________________________________________________________
> 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
>

Right, what Dan said. And yes I have a list of people in my head to look 
at certain things, especially around PCI, Rbd, live migration, xen, 
hyperv, etc. I pull them into reviews regularly when I feel the need. 
That's also an indirect way that I can gauge how some people handle 
reviews, and what they look for, which in turn gets them on my list of 
core candidates, assuming they are actively involved in the project.

I'd also like to say that I dislike the constant comparisons to the 
kernel. If people are going to make that comparison, then let's say the 
kernel overall is all of OpenStack, and there are subsystems, like 
nova/cinder/glance/etc, with their own subsystem maintainers, e.g. 
nova-core.

I'd also like to note that I personally don't think the bar to nova core 
is as high as some people make it out to be. There is a high standard, 
but meeting that standard isn't impossible. For me it means involvement, 
maintenance, willingness to own and fix problems, and helpful code 
reviews. I'll also say I notice people that -1 more often than people 
that +1. That doesn't mean I expect all nova core reviewers to know all 
parts of nova, I certainly don't. We have several cores that mostly only 
review certain parts of the code, the API being a good example. But they 
are definitely experts in that code and own a lot of it, and I trust 
them enough to show restraint when reviewing things they aren't experts 
on (so a +1 maybe, or +2 on obvious changes).

I'll also note that 'good code' is subjective. What someone thinks is a 
worthwhile and useful change might actually break some other part of the 
system, or break under a certain configuration. Obviously we don't have 
100% CI coverage, we never will. And not everyone has all of this in 
their head, that's already been noted. But I don't think it's fair to 
say that just because someone thinks 'this is the greatest thing since 
sliced bread so let's get it in with a single nova-core +2' is the right 
approach. That's my personal opinion.

So I'm still -1 on the subsystem cores idea. I think it would mean 
increased throughput but at the expense of fewer nova-cores reviewing a 
change with hopefully some context of the broader impact of said change.

-- 

Thanks,

Matt Riedemann