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. In the end, as others have said, the biggest problem by far is just that we need more of the right people reviewing code. -- Russell Bryant _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev