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.tho...@gmail.com >> <mailto:duncan.tho...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev