<p dir="ltr">On Nov 8, 2016 1:13 PM, "Matt Riedemann" <<a href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>> wrote:<br>
><br>
> On 11/8/2016 11:39 AM, Dan Smith wrote:<br>
>>><br>
>>> I do imagine, however, that most folks who have been working<br>
>>> on nova for long enough have a list of domain experts in their heads<br>
>>> already. Would actually putting that on paper really hurt?<br>
>><br>
>><br>
>> You mean like this?<br>
>><br>
>> <a href="https://wiki.openstack.org/wiki/Nova#Developer_Contacts">https://wiki.openstack.org/wiki/Nova#Developer_Contacts</a><br>
>><br>
>> Those are pretty much the people I look to have sign off on a thing I'm<br>
>> not completely familiar with before approving something. I'm sure it<br>
>> could use some updating, of course.<br>
>><br>
>> This is linked from the MAINTAINERS file in our tree, by the way.<br>
>><br>
>> --Dan<br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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).<br>
><br>
> 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.<br>
><br>
> 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.</p>
<p dir="ltr">Apologies in advance for the email formatting. I'm writing this from my phone at an airport..</p>
<p dir="ltr">As I mentioned in Barcelona, I'm supportive of a trial of Mr. Booth's idea with a commitment to gathering data about total review load, merge velocity and some kind of metric to assess code quality impact. I think we need to increase the amount of code being merged in specific areas of the Nova codebase but recognize the inherent danger of opening things up too quickly on a highly complex piece of source code.</p>
<p dir="ltr">In short, I'd like to get pre and post data and then give the +2 but not +W concept a shot and see if things improve with regards to merge velocity in certain areas.</p>
<p dir="ltr">Best,<br>
-jay<br><br><br></p>