linux-kernel - Re: [git pull] drm request 2

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 2 Mar 2010 15:40:59 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Airlie <airlied@...il.com>
cc:	Dave Airlie <airlied@...ux.ie>, dri-devel@...ts.sf.net,
	linux-kernel@...r.kernel.org
Subject: Re: [git pull] drm request 2

On Wed, 3 Mar 2010, Dave Airlie wrote:
>
> Did I mention that driver is in STAGING?

Staging is for _improving_ the quality of the drivers, not for making it 
worse.

We still very much have quality standards. The staging tree is for things 
to get in that don't quite _reach_ the standards we expect, but it's not a 
blanket excuse for not testing things.

And yes, I expect that stuff can be a bit rough during the merge window, 
after all, the whole point is that we can fix things up. But quite 
frankly, if _I_ find problems on the few machines I personally build and 
test on, then what does that say about the bigger picture?

IOW, I refuse to pull code that doesn't even work for me. If I did, where 
would we end up? What do you think should be my minimal quality 
requirements, if "Oh, it doesn't even build for me" is too much to ask 
for?

So if I find code that doesn't work, I'm not going to just say "whatever". 
I'm going to reject it.

			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/