Good idea! Only thing I would point out is there are a fair amount of changes, especially lately, where code is just moving from one portion of the project to another, so there may be cases where someone ends up being authoritative over code they don't totally understand.
From: Alessandro Pilotti <apilo...@cloudbasesolutions.com<mailto:apilo...@cloudbasesolutions.com>> Reply-To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, August 27, 2013 10:48 AM To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Nova] Frustrations with review wait times On Aug 27, 2013, at 18:40 , Joe Gordon <joe.gord...@gmail.com<mailto:joe.gord...@gmail.com>> wrote: On Tue, Aug 27, 2013 at 11:04 AM, Daniel P. Berrange <berra...@redhat.com<mailto:berra...@redhat.com>> wrote: On Tue, Aug 27, 2013 at 10:55:03AM -0400, Russell Bryant wrote: > On 08/27/2013 10:43 AM, Daniel P. Berrange wrote: > > I tend to focus the bulk of my review activity on the libvirt driver, > > since that's where most of my knowledge is. I've recently done some > > reviews outside this area to help reduce our backlog, but I'm not > > so comfortable approving stuff in many of the general infrastructure > > shared areas since I've not done much work on those areas of code. > > > > I think Nova is large enough that it (mostly) beyond the scope of any > > one person to know all areas of Nova code well enough todo quality > > reviews. IOW, as we grow the nova-core team further, it may be worth > > adding more reviewers who have strong knowledge of specific areas & > > can focus their review energy in those areas, even if their review > > count will be low when put in the context of nova as a whole. > > I'm certainly open to that. > > Another way I try to do this unofficially is give certain +1s a whole > lot of weight when I'm looking at a patch. I do this regularly when > looking over patches to hypervisor drivers I'm not very familiar with. > > Another thing we could consider is take this approach more officially. > Oslo has started doing this for its incubator. A maintainer of a part > of the code not on oslo-core has their +1 treated as a +2 on that code. > > http://git.openstack.org/cgit/openstack/oslo-incubator/tree/MAINTAINERS Yes, just having a list of expert maintainers for each area of Nova would certainly be helpful in identifying whose comments to place more weight by, regardless of anything else we might do. I think we can dynamically generate this based on git log/blame and gerrit statistics per file. For example if someone has authored half the lines in a file or reviewed most of the patches that touched that file, they are probably are very familiar with the file and would be a good person to review any change. +1 :-) Daniel -- |: http://berrange.com<http://berrange.com/> -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org<http://libvirt.org/> -o- http://virt-manager.org<http://virt-manager.org/> :| |: http://autobuild.org<http://autobuild.org/> -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org<http://entangle-photo.org/> -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
