kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: greg@kroah.com (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: A quick guide to why stand-alone checkpatch patches suck...
Date: Tue, 16 Sep 2014 21:56:28 -0700	[thread overview]
Message-ID: <20140917045628.GB19159@kroah.com> (raw)
In-Reply-To: <153669.1410925338@turing-police.cc.vt.edu>

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.

thanks,

greg k-h

  reply	other threads:[~2014-09-17  4:56 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-17  0:25 A quick guide to why stand-alone checkpatch patches suck Valdis Kletnieks
2014-09-17  0:37 ` Greg KH
2014-09-17  1:35 ` Greg Donald
2014-09-17  3:42   ` Valdis.Kletnieks at vt.edu
2014-09-17  4:56     ` Greg KH [this message]
2014-09-17  5:43       ` Sudip Mukherjee
2014-09-17 10:39       ` Robert P. J. Day
2014-09-17 11:20       ` Robert P. J. Day
2014-09-17 11:38         ` nick
2014-09-17 11:51           ` Sudip Mukherjee
2014-09-17 11:53             ` nick
2014-09-17 12:05               ` Greg Freemyer
2014-09-17 12:09                 ` nick
2014-09-17 12:17                   ` Kai Bojens
2014-09-17 12:23                     ` nick
2014-09-17 12:25                   ` Greg Freemyer
2014-09-17 12:29                     ` Nick Krause
2014-09-17 14:39                   ` Valdis.Kletnieks at vt.edu
2014-09-17 11:53           ` Robert P. J. Day
2014-09-17 11:55             ` nick
2014-09-17 12:17               ` Chris Lee
2014-09-17 12:19                 ` nick
2014-09-17 11:56         ` Greg Freemyer
2014-09-17 12:00           ` Robert P. J. Day
2014-09-17 12:05             ` nick
2014-09-17 12:02           ` nick
2014-09-17 14:39             ` Valdis.Kletnieks at vt.edu
2014-09-17 17:04               ` Nick Krause
2014-09-17 17:13               ` Bruno Guedes Souto
2014-09-17 17:47                 ` Nick Krause
2014-09-17 18:01                   ` Philipp Muhoray
2014-09-17 18:14                     ` Nick Krause
2014-09-17 18:15                   ` Robert P. J. Day
2014-09-17 18:44                     ` Nick Krause
2014-09-17 20:45                 ` John de la Garza

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140917045628.GB19159@kroah.com \
    --to=greg@kroah.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).