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

[Greg KH <greg@kroah.com>]

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.

> 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?

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.  It's _really_ hard to get involved in
OpenStack, by design.  The kernel is not that way, and hopefully never
will be, as we want to succeed...

greg k-h