Open Stack

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 <apilotti at cloudbasesolutions.com<mailto:apilotti at cloudbasesolutions.com>>
Reply-To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Tuesday, August 27, 2013 10:48 AM
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Nova] Frustrations with review wait times

On Aug 27, 2013, at 18:40 , Joe Gordon <joe.gordon0 at gmail.com<mailto:joe.gordon0 at gmail.com>>
 wrote:




On Tue, Aug 27, 2013 at 11:04 AM, Daniel P. Berrange <berrange at redhat.com<mailto:berrange at 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 at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130827/1d9abd90/attachment.html>