[openstack-dev] [nova] A modest proposal to reduce reviewer load

Joe Gordon joe.gordon0 at gmail.com
Tue Jun 17 16:22:47 UTC 2014


On Tue, Jun 17, 2014 at 3:56 AM, Duncan Thomas <duncan.thomas at gmail.com>
wrote:

> A far more effective way to reduce the load of trivial review issues
> on core reviewers is for none-core reviewers to get in there first,
> spot the problems and add a -1 - the trivial issues are then hopefully
> fixed up before a core reviewer even looks at the patch.
>
> The fundamental problem with review is that there are more people
> submitting than doing regular reviews. If you want the review queue to
> shrink, do five reviews for every one you submit. A -1 from a
> none-core (followed by a +1 when all the issues are fixed) is far,
> far, far more useful in general than a +1 on a new patch.
>

++

I think this thread is trying to optimize for the wrong types of patches.
 We shouldn't be focusing on making trivial patches land faster, but rather
more important changes such as bugs and blueprints. As some simple code
motion won't directly fix any users issue such as bugs or missing features.


>
>
>
> On 17 June 2014 11:04, Matthew Booth <mbooth at redhat.com> wrote:
> > We all know that review can be a bottleneck for Nova patches.Not only
> > that, but a patch lingering in review, no matter how trivial, will
> > eventually accrue rebases which sap gate resources, developer time, and
> > will to live.
> >
> > It occurs to me that there are a significant class of patches which
> > simply don't require the attention of a core reviewer. Some examples:
> >
> > * Indentation cleanup/comment fixes
> > * Simple code motion
> > * File permission changes
> > * Trivial fixes which are obviously correct
> >
> > The advantage of a core reviewer is that they have experience of the
> > whole code base, and have proven their ability to make and judge core
> > changes. However, some fixes don't require this level of attention, as
> > they are self-contained and obvious to any reasonable programmer.
> >
> > Without knowing anything of the architecture of gerrit, I propose
> > something along the lines of a '+1 (trivial)' review flag. If a review
> > gained some small number of these, I suggest 2 would be reasonable, it
> > would be equivalent to a +2 from a core reviewer. The ability to set
> > this flag would be a privilege. However, the bar to gaining this
> > privilege would be low, and preferably automatically set, e.g. 5
> > accepted patches. It would be removed for abuse.
> >
> > Is this practical? Would it help?
> >
> > Matt
> > --
> > Matthew Booth
> > Red Hat Engineering, Virtualisation Team
> >
> > Phone: +442070094448 (UK)
> > GPG ID:  D33C3490
> > GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Duncan Thomas
>
> _______________________________________________
> OpenStack-dev mailing list
> 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/20140617/df27e7ba/attachment.html>


More information about the OpenStack-dev mailing list