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-requ...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
