From: Andi Kleen <andi@firstfloor.org>
To: Theodore Tso <tytso@mit.edu>, Andi Kleen <andi@firstfloor.org>,
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 20:41:29 +0100 [thread overview]
Message-ID: <20080104194129.GA16962@one.firstfloor.org> (raw)
In-Reply-To: <20080104190137.GJ17436@mit.edu>
> 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
The problem I see is that if someone has a more involved outstanding
patch series against the code that is being cleaned up (and more complicated
features tend to require some time to stabilize so "just merge early"
is not always the solution) then it is a serious mess to readapt
a patch series to the cleanups. Yes it can be all done but it wastes
time that would be more constructively used e.g. for better testing.
Now if some area is changed anyways then they're usually ok because
all outstanding patches will need to be adapted anyways.
So I guess a useful rule for cleanup patches would be "only if that
code changed recently"
> > 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?
My pet theory is that it is similar to the "unsubscribe me"
cascade effect you sometimes see on mailing lists. One person
sends a "unsubscribe me" to everybody and then suddenly a lot of
people think that is the right way to unsubscribe and reply
with lots of "unsubscribe me too".
So one person sends a cleanup and it gets accepted and suddenly
other people realize it is very easy to do these cleanups
(not realizing the hidden costs they have) and then they go on...
I thought we had the janitor project to steer these people into
more useful directions, but apparently that is not well known
enough anymore. Perhaps it just needs to be more regularly announced?
Although I must admit I am not 100% happy with kernel-janitors
either -- e.g. a few times I sent suggestions about easy things
someone could do to that list, but never heard anything back.
Anyways there are lots of ways to do trivial cleanups in a useful
way and if people want to do this perhaps they should just
ask on linux-kernel and people suggest something?
My hope here is of course that these trivial changes are primarily
used as a way to get "the feet wet" to understand the procedures
for contribuing larger not quite as trivial changes
-Andi
P.S.: Mathieu, this is not against you personally; you just happened
to be a convenient example of a larger problem in this case. Sorry.
next prev parent reply other threads:[~2008-01-04 19:39 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
2008-01-04 19:41 ` Andi Kleen [this message]
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=20080104194129.GA16962@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=akpm@linux-foundation.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.segaud@regala.cx \
--cc=tytso@mit.edu \
/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