A quick guide to why stand-alone checkpatch patches suck...

[Robert P. J. Day]

On Tue, 16 Sep 2014, Greg KH wrote:

> On Tue, Sep 16, 2014 at 11:42:18PM -0400, Valdis.Kletnieks at vt.edu wrote:
> > (And this sort of analysis is exactly *why* people need to apply their brains
> > when looking at checkpatch output....)
>
> No one has ever said that they shouldn't.
>
> Remember, I know _lots_ of kernel developers who started with just
> "checkpatch cleanups on staging drivers" and they moved on to much
> "higher" roles in the kernel developer ecosystem (jobs, maintainers
> of subsystems, keynote talks at conferences, etc.)
>
> Don't "po po" it as something that shouldn't be a valid place to
> start, it is, and is why I do the work to review all of the many
> thousands of staging patches every release cycle.
>
> No one is forcing you to write those patches, or read / review them,
> so don't discourage others to provide them either please.  I most
> certainly do not.

  as someone who started out this way (submitting "trivial" patches,
and still do from time to time) and who now makes a living teaching
kernel programming and embedded linux and device drivers, perhaps i
can add some perspective, and also explain why nick krause is
monstrously off-base in everything he touches.

  of *course* it's useful that beginners get the opportunity to submit
trivial patches based on nothing but perhaps checkpatch warnings --
it's a great way to get your feet wet, burn in the lessons of how to
write and submit a proper patch, and so on and so on.  but notice the
really important point gregkh makes here:

> Remember, I know _lots_ of kernel developers who started with just
> "checkpatch cleanups on staging drivers" and they moved on to much
> "higher" roles in the kernel developer ecosystem (jobs, maintainers
> of subsystems, keynote talks at conferences, etc.)

the obvious implication is that, while you *start* simple, the goal is
to ***move up***. trivial, style-based patches are a great
*introduction*, but everyone should have the eventual goal of more and
more sophisticated patches and contributions involving tweaking code
and eventually writing new subsystems, etc, etc. and this is where
nick krause is failing miserably.

  nick shows absolutely no interest in understanding the code he's
looking at. his approach to patches is to blindly run checkpatch, look
at the first warning, go to that file, and try to "fix" it, without in
any way whatsoever trying to understand the code in a larger context.
if checkpatch says to add blank lines, nick will add blank lines,
after which he will understand no more about the code than when he
started, which is why, regardless of how long nick does this, he will
never, ever, ever understand any more about the kernel than he does
now.

  nick has made it obvious he has no interest in actually
understanding how the kernel works -- all he is obsessed with is
getting his name into the git log as the author of a patch; hence, his
relentless labour in submitting variation after variation of a patch
that does nothing more than add three blank lines to a single file.

  nick has long since lost sight of what that single source file is
doing (if he ever even cared what it did in the first place). he is
now in a very unhealthy place where he is going to get those blank
lines in there if it kills him or pisses off every single person on
the kernelnewbies mailing list, and that is precisely why working with
him is a complete waste of time.

  other beginners will start where nick is now and, in short order,
they will progress to bigger and better things -- as greg kh suggests,
writing code, becoming subsystem maintainers, giving keynotes. nick
will never, ever, ever do any of this; five years from now, nick will
still blindly be running checkpatch, then going to files looking for
blank lines to add. he will never progress beyond that, simply because
he's doing this for all the wrong reasons.

  nick doesn't care about how the kernel works. nick just wants to get
a patch in there somewhere ... anywhere, it doesn't matter. which is
why he is not worth anyone's time. nick will never be a useful
contributor to the kernel community because, in the end, he doesn't
really care about the kernel.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================