linux-kernel - Re: Slow DOWN, please!!!

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]

Message-ID: <alpine.LFD.1.10.0804301919080.5994@woody.linux-foundation.org>
Date:	Wed, 30 Apr 2008 19:30:13 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Adrian Bunk <bunk@...nel.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>, rjw@...k.pl,
	davem@...emloft.net, linux-kernel@...r.kernel.org,
	jirislaby@...il.com
Subject: Re: Slow DOWN, please!!!

On Thu, 1 May 2008, Adrian Bunk wrote:
> 
> I am saying that it was merged too early, and that there are points that 
> should have been addressed before the driver got merged.
> 
> Get it submitted for review to linux-kernel.
> Give the maintainers some time to incorporate all comments.
> Even one month later it could still have made it into 2.6.25.
> 
> The only problem with my suggestion is that it's currently pretty random 
> whether someone takes the time to review such a driver on linux-kernel.

Now, I do agree that we could/should have some more process in general. I 
really _would_ like to have a process in place that basically says:

 - everything must have gone through lkml at least once

 - after that point, it should have been in linux-next or the -mm queue

 - and then it can get merged (and if it didn't get any review by then, 
   maybe it was because nobody was interested, and it simply won't be 
   getting any until it oopses or catches peoples interest some other way)

HOWEVER.

That process doesn't actually work for everything anyway (a lot of trivial 
fixes are really best not being so noisy, and various patches that are 
specific to some subsystem really _are_ better off just discussed on that 
subsystem mailing lists).

And perhaps more pertinently, right now that kind of process is very 
inconvenient (to the point of effectively being impossible) for me to 
check. Obviously, if the patch comes from Andrew, I know it was in -mm, 
and I seldom drop those patches for obvious reasons anyway, but the last 
thing we want is some process that depends even _more_ on Andrew being a 
burnt-out-excuse-for-a-man in a few years (*).

So I could ask for people to always have pointers to "it was discussed 
here" on patches they send (and I'd likely mostly trust them without even 
bothering to verify), the same way -git maintainers often talk about "most 
of this has been in -mm for the last two months".

That might work. But then there would still be the patches that are 
obvious and don't need them.

And then even the obvious patches do break. And people will complain. Even 
though requiring that kind of process for the stupid stuff would just slow 
everybody down, and would be really painful.

So one of my _personal_ reasons I don't want to put too much process in 
place is that I don't think process is appropriate for everything, and yet 
even the stuff that obviously doesn't need or want process (speling fixes 
and build failures) _will_ cause problems, and then people will whine 
about them not being there.

			Linus

(*) Andrew, no offense. I'm sure you'd be a magnificent burnt-out-excuse- 
for-a-man.
--
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/