All of lore.kernel.org
 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 17:37:35 -0700	[thread overview]
Message-ID: <20140917003735.GA17666@kroah.com> (raw)
In-Reply-To: <140649.1410913551@turing-police.cc.vt.edu>

On Tue, Sep 16, 2014 at 08:25:51PM -0400, Valdis Kletnieks wrote:
> In general, stand-alone patches to "fix" checkpatch whining are a Bad Idea(TM).

<snip>

And here's why checkpatch patches are a "Good Idea(TM)":
  - it teaches you how to set up your email client properly
  - it teaches you how to describe a patch properly
  - it teaches you how to submit a patch properly
  - it gives you a good feedback loop
  - it is an "easy" place to start.

But, and this is a huge BUT, which you ignored, you should ONLY submit a
checkpatch cleanup for a subsystem that has a maintainer that welcomes
them.

Like drivers/staging/*.  Checkpatch cleanups are welcome, and encouraged
there.  If you want to do a checkpatch cleanup, do it there, you will
not be yelled at.

thanks,

greg k-h

  reply	other threads:[~2014-09-17  0:37 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 [this message]
2014-09-17  1:35 ` Greg Donald
2014-09-17  3:42   ` Valdis.Kletnieks at vt.edu
2014-09-17  4:56     ` Greg KH
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=20140917003735.GA17666@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.