[openstack-dev] [nova] A modest proposal to reduce reviewer load
mbooth at redhat.com
Wed Jun 18 08:32:34 UTC 2014
On 17/06/14 17:55, Russell Bryant wrote:
> On 06/17/2014 12:22 PM, Joe Gordon wrote:
>> On Tue, Jun 17, 2014 at 3:56 AM, Duncan Thomas <duncan.thomas at gmail.com
>> <mailto: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.
> In fact, landing easier and less important changes causes churn in the
> code base can make the more important bugs and blueprints even *harder*
> to get done.
I see 3 principal advantages to getting trivial changes out of the queue
* It reduces unnecessary rebases. The longer your code motion patch
languishes, the more times you're going to have to rebase it.
* It encourages submitters to break patches down in to a larger number
of smaller pieces. This makes it much simpler to understand and validate
a large change.
* It reduces frustration. It is soul destroying to have to wait weeks
for somebody to agree that you fixed a typo. Unhappy developers can
> In the end, as others have said, the biggest problem by far is just that
> we need more of the right people reviewing code.
Agreed, but a resource squeeze is often a good time to see
optimisations. A small improvement is still an improvement :)
 This series is very nice: https://review.openstack.org/#/c/98604/
 In fact, I'm aware of a significant amount of cleanup which hasn't
happened because of this.
Red Hat Engineering, Virtualisation Team
Phone: +442070094448 (UK)
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
More information about the OpenStack-dev