Open Stack

On Nov 8, 2016 1:13 PM, "Matt Riedemann" <mriedem at linux.vnet.ibm.com> wrote:
>
> 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.

Apologies in advance for the email formatting. I'm writing this from my
phone at an airport..

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.

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.

Best,
-jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161108/a6053a76/attachment.html>