public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Andi Kleen <andi@firstfloor.org>
Cc: Mathieu Segaud <mathieu.segaud@regala.cx>,
	akpm@linux-foundation.org, linux-ext4@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [Coding Style]: misc fixes for fs/ext{3,4}/acl.{c,h} from checkpatch.pl
Date: Fri, 4 Jan 2008 14:01:37 -0500	[thread overview]
Message-ID: <20080104190137.GJ17436@mit.edu> (raw)
In-Reply-To: <p73hcht8sfr.fsf@bingen.suse.de>

On Fri, Jan 04, 2008 at 05:30:00PM +0100, Andi Kleen wrote:
> 
> Exactly. And looking at the patch the old code was already perfectly
> readable anyways. Benefit about zero.

File this under the "checkpatch.pl" considered harmful category....
The problem is not with the tool, but that at least *some* people seem
to think that making checkpatch.pl be completely silent is somehow
this holy grail that will make kernel code bug-free(tm).  (And of
course, people who want to encode nazi-like coding conventions and to
force all of the kernel to use a single coding convention as if that
somehow would improve the kernel's quality.  Some of that is OK, but
as long as the code is readable, do we really care about whether or
not the code is using exactly the same coding conventions everyplace?
Or, pressuring maintainers not to ignore cleanup patches lest they be
viewed as "bad" maintainers?)

Personally I find it annoying, but I'm willing to live with the
cleanup patches.  I don't think they add anything, though.  Maybe I
should be more cranky about such patches....

> The recent flurry of cleanup code patches on l-k causes far more
> problems than it solves. I'm not even sure why people do this? Just
> because it is en vogue recently? 

I don't know, because people want to be able to say that they've
contributed fixes to the Linux kernel?

I will say that in past kernel summit program commitees, the
perception that someone _only_ submitted trivial patches (i.e.,
whitespace-only, spelling fixes in comments, etc.) has sometimes been
perceived a negative factor towards whether the program committee
might consider that person to be useful contributor to discussions at
the kernel summit....  So people should be warned (I would have hoped
that it would be obvious), that submitting vast number of trivial
cleanup patches without contributing anything else will very likely
not work, and possibly backfire if that is your goal.

							- Ted

  reply	other threads:[~2008-01-04 19:01 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-04 13:21 [PATCH] [Coding Style]: misc fixes for fs/ext{3,4}/acl.{c,h} from checkpatch.pl Mathieu Segaud
2008-01-04 13:21 ` [PATCH] [Coding Style]: fs/ext{3,4}/balloc.c Mathieu Segaud
2008-01-04 13:21   ` [PATCH] [Coding Style]: fs/ext{3,4}/bitmap.c Mathieu Segaud
2008-01-04 13:21     ` [PATCH] [Coding Style]: fs/ext{3,4}/dir.c Mathieu Segaud
2008-01-04 13:21       ` [PATCH] [Coding Style]: fs/ext{3,4}/ext{3,4}_jbd{,2}.c Mathieu Segaud
2008-01-04 13:41         ` Richard Knutsson
2008-01-04 13:47           ` Mathieu SEGAUD
2008-01-05  4:12           ` Andreas Dilger
2008-01-05  4:47             ` Dmitri Vorobiev
2008-01-05  4:48             ` Dmitri Vorobiev
2008-01-05  5:18             ` Al Viro
2008-01-10 21:03               ` Roel Kluin
2008-01-11  3:09                 ` Peter Stuge
2008-01-11  3:42                   ` Paul Mundt
2008-01-11  3:46                     ` Peter Stuge
2008-01-11  9:45                     ` Roel Kluin
2008-01-11 10:29                       ` Paul Mundt
2008-01-11 11:04                         ` Roel Kluin
2008-01-11 11:23                           ` Paul Mundt
2008-01-11 12:27                             ` Roel Kluin
2008-01-04 13:44 ` [PATCH] [Coding Style]: misc fixes for fs/ext{3,4}/acl.{c,h} from checkpatch.pl Theodore Tso
2008-01-04 13:49   ` Mathieu SEGAUD
2008-01-04 13:56     ` Theodore Tso
2008-01-04 16:30   ` Andi Kleen
2008-01-04 19:01     ` Theodore Tso [this message]
2008-01-04 19:41       ` Andi Kleen
2008-01-04 20:01         ` Cyrill Gorcunov
2008-01-04 20:03         ` Paolo Ciarrocchi
2008-01-04 22:33           ` Andi Kleen
2008-01-05  0:12             ` Paolo Ciarrocchi
2008-01-05  0:39               ` Theodore Tso
2008-01-05 21:24                 ` Jan Engelhardt

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=20080104190137.GJ17436@mit.edu \
    --to=tytso@mit.edu \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.segaud@regala.cx \
    /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