Re: [Ksummit-discuss] [TOPIC] Encouraging more reviewers

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2014-05-29 at 16:34 -0700, Greg KH wrote:
> On Thu, May 29, 2014 at 10:13:21AM +0400, James Bottomley wrote:
> > I suspect, but cannot prove, it is somewhat driven by the patch
> > statistics.  I know in Parallels, I track features accepted into the
> > kernel, not patches, but we do have a patch metric as well for people
> > who do incidental bug fixing as they push features, so we're not 100%
> > pure on this.
> > 
> > When I recently gave a comparison of OpenStack and the Kernel, one thing
> > that stood out starkly was that they just don't have our volume of one
> > line, one patch per file hundreds of times and trivial changes, so we
> > definitely have a problem in this area.
> > 
> > The reason OpenStack has so few trivial and multiply split patches is
> > mostly grounded in the difficulty of submitting a patch to their tree.
> 
> And I would argue that this is going to be a long-term problem for them.

Well, I think they make it too hard, but I think they also demonstrate
that some friction in the process is a useful refiner.

> > Just preparing it for gerrit takes a long time (around ten minutes per
> > patch), which really reduces the volume of trivial patches, just because
> > no-one has that much energy (although some would argue it reduces the
> > volume too far).
> > 
> > It's human nature to spend more time on the easy problems, so a flood of
> > trivial patches which are "obviously" correct is easier to review and
> > include than one patch which alters something deep within mm and needs
> > careful thought.  At best, excessively split trivial patches are a
> > dilution of our review effort and at worst, they're actively sucking
> > people away from tackling the hard problems.
> 
> I have not heard of these "cleanup" patches taking anyone's review
> cycles up for the "harder" patches, do you have examples of it?

Yes, me.

> In fact, I would argue the fact that we do so easily accept cleanups
> across the board that keeps our developer community engaged and new
> people joining in easy.

OK, so this is a difference in style.  I prefer the find a bug and fix
it approach.  The thing that worries me about cleanup for its own sake
is that we're developing ever more elaborate tools to detect pattern
changes, so it's spawning an industry in its own right and some people
see it as an end in itself, not a precursor to graduating to substantive
changes.

I also have no objections to cleanup coupled with substantive changes.
In fact, when someone wants to clean up one of the old and crufty
drivers, I say yes, provided they can maintain it.  We've had a couple
of successes in this regard.

James