Open Stack

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
quickly:

* 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[1].

* It reduces frustration. It is soul destroying to have to wait weeks
for somebody to agree that you fixed a typo[2]. Unhappy developers can
be poisonous.

> 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 :)

Matt

[1] This series is very nice: https://review.openstack.org/#/c/98604/

[2] In fact, I'm aware of a significant amount of cleanup which hasn't
happened because of this.
-- 
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