[openstack-dev] [Nova] Frustrations with review wait times

Alessandro Pilotti apilotti at cloudbasesolutions.com
Tue Aug 27 15:48:50 UTC 2013


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/f180566b/attachment.html>


More information about the OpenStack-dev mailing list