public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Halasa <khc@pm.waw.pl>
To: Daniel Walker <dwalker@fifo99.com>
Cc: rostedt@goodmis.org, Andy Whitcroft <apw@canonical.com>,
	Li Zefan <lizf@cn.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/5] checkpatch: add a blacklist
Date: Wed, 07 Oct 2009 23:30:27 +0200	[thread overview]
Message-ID: <m3my42uc24.fsf@intrepid.localdomain> (raw)
In-Reply-To: <1254929907.18167.301.camel@desktop> (Daniel Walker's message of "Wed, 07 Oct 2009 08:38:27 -0700")

Daniel Walker <dwalker@fifo99.com> writes:

> Just relax the submission rules so that checkpatch is basically an
> optional part of the submission process. Adding that you don't actually
> need to run it, you don't need a good reason not to follow the rules
> etc.. Or expand on it to fully explain what you think the deal is or
> should be.

Oh come on... The SubmittingPatches is a HOWTO-style document for people
who want to get their patches merged. Obviously a common sense dictates
you need a good reason to ignore this or that. "Looks better" and
"I find it easier to work with" are good reasons since this is source
code, for humans to work with.

BTW, the file says:

"Check your patches with the patch style checker prior to submission
(scripts/checkpatch.pl).  The style checker should be viewed as
a guide not as the final word.  If your code looks better with
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
a violation then its probably best left alone.

The checker reports at three levels:
 - ERROR: things that are very likely to be wrong
                               ^^^^^^
 - WARNING: things requiring careful review
 - CHECK: things requiring thought"

Only "very likely".

WRT tabs vs spaces, I wonder if using only spaces would be a better
idea. Theoretically using tabs for syntactic indentation only is better,
but the tools (editors) aren't up to the task yet.
-- 
Krzysztof Halasa

  reply	other threads:[~2009-10-07 21:31 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-22  2:14 [PATCH 1/5] checkpatch: fix false errors due to macro concatenation Daniel Walker
2009-09-22  2:14 ` [PATCH 2/5] checkpatch: fix hang in relative indent checking Daniel Walker
2009-09-22  2:14   ` [PATCH 3/5] checkpatch: add a blacklist Daniel Walker
2009-09-22  2:14     ` [PATCH 4/5] checkpatch: fix __attribute__ matching Daniel Walker
2009-09-22  2:14       ` [PATCH 5/5] checkpatch: fix false EXPORT_SYMBOL warning Daniel Walker
2009-09-30 17:46         ` Andy Whitcroft
2009-10-01 14:28           ` Daniel Walker
2009-10-02  7:39             ` Andy Whitcroft
2009-09-30 17:46       ` [PATCH 4/5] checkpatch: fix __attribute__ matching Andy Whitcroft
2009-10-01 14:26         ` Daniel Walker
2009-10-02  7:43           ` Andy Whitcroft
2009-09-22  6:29     ` [PATCH 3/5] checkpatch: add a blacklist Li Zefan
2009-09-30 15:27       ` Andy Whitcroft
2009-10-01 14:18         ` Daniel Walker
2009-10-06 19:51           ` Steven Rostedt
2009-10-06 20:50           ` Krzysztof Halasa
2009-10-07  3:52             ` Daniel Walker
2009-10-07 10:17               ` Krzysztof Halasa
2009-10-07 14:26                 ` Daniel Walker
2009-10-07 14:44                   ` Krzysztof Halasa
2009-10-07 14:57                     ` Daniel Walker
2009-10-07 15:11                       ` Alan Cox
2009-10-07 15:41                         ` Daniel Walker
2009-10-07 15:52                           ` Alan Cox
2009-10-07 16:11                             ` Daniel Walker
2009-10-07 15:08                   ` Steven Rostedt
2009-10-07 15:38                     ` Daniel Walker
2009-10-07 21:30                       ` Krzysztof Halasa [this message]
2009-10-07 21:58                         ` Daniel Walker
2009-09-30 15:24   ` [PATCH 2/5] checkpatch: fix hang in relative indent checking Andy Whitcroft
2009-09-30 17:46 ` [PATCH 1/5] checkpatch: fix false errors due to macro concatenation Andy Whitcroft
2009-10-01 14:20   ` Daniel Walker

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=m3my42uc24.fsf@intrepid.localdomain \
    --to=khc@pm.waw.pl \
    --cc=akpm@linux-foundation.org \
    --cc=apw@canonical.com \
    --cc=dwalker@fifo99.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=rostedt@goodmis.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