linux-ext4 - Re: [PATCH] [Coding Style]: misc fixes for fs/ext{3,4}/acl.{c,h} from checkpatch.pl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 4 Jan 2008 20:41:29 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Theodore Tso <tytso@....edu>, Andi Kleen <andi@...stfloor.org>,
	Mathieu Segaud <mathieu.segaud@...ala.cx>,
	akpm@...ux-foundation.org, linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [Coding Style]: misc fixes for fs/ext{3,4}/acl.{c,h} from checkpatch.pl

> 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html