Open Stack

On Tue, Jun 17, 2014 at 12:55:26PM -0400, 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.

None the less I think it is worthwhile having a way to tag trivial
bugs so we can easily identify them. IMHO if there's a way we can
improve turnaround time on such bugs it is worth it, if only to
stop authors getting depressed with the wait for trivial/obvious
fixes.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|