[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.00.0802211310370.19896@woody.linux-foundation.org>
Date: Thu, 21 Feb 2008 13:14:55 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Adrian Bunk <bunk@...nel.org>
cc: Roland Dreier <rdreier@...co.com>,
Glenn Streiff <gstreiff@...Effect.com>,
Faisal Latif <flatif@...Effect.com>,
linux-kernel@...r.kernel.org, general@...ts.openfabrics.org,
Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <greg@...ah.com>
Subject: Re: Merging of completely unreviewed drivers
On Thu, 21 Feb 2008, Adrian Bunk wrote:
>
> Is it really intended to merge drivers without _any_ kind of review?
I'd really rather have the driver merged, and then *other* people can send
patches!
The thing is, that's what merging really means - people can work on it
sanely together. Before it's merged, it's a lot harder for people to work
on it unless they are really serious about that driver, so before
merging, the janitorial kind of things seldom happen.
So yes, I really do believe that we should merge drivers in particular a
lot more aggressively. I'd like to see *testing* feedback, in order to not
merge drivers that simply don't work well enough, but anything else? I
suspect other feedback is as likely to cause problems as it is to fix
things.
> This driver even lacks a basic "please fix the > 250 checkpatch errors" [1]
> and similar low hanging fruits that could easily be spotted and then
> fixed by the submitter within a short amount of time.
Quite frankly, I've several times been *this* close (holds up fingers so
you can't even see between them) to just remove checkpatch entirely.
I'm personally of the opinion that a lot of checkpatch "fixes" are
anything but. That mainly concerns fixing overlong lines (where the
"fixed" version is usually worse than the original), but it's been true
for some other warnings too.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists