linux-kernel - Re: [git pull] drm fixes

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:	Mon, 7 Jun 2010 14:03:46 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Airlie <airlied@...il.com>
cc:	Dave Airlie <airlied@...ux.ie>, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org
Subject: Re: [git pull] drm fixes

On Tue, 8 Jun 2010, Dave Airlie wrote:
> 
> Oh the one where I said to the reporter, I've reproduced this, and
> will fix it tomorrow when I have proper time and access to my test
> machine?
> 
> I didn't think writing a fix in the 5 mins before I left the test
> machine and sending it you was acceptable, again can you maintain some
> semblance of consistency across maintainers/releases?

No, no. I really didn't imply that you should hurry and not be careful. I 
was just unhappy about the mixing of non-regression fixes with the 
regression fixes.

> Like I'm happy if you really enforce this no features idea, I'd be
> really happy if you did it every release since it makes it a lot
> easier to push back to submaintainers if you can point at Linus not
> pulling features from people.

I already had another person state their happiness with me pushing back, 
and while I had my reasons for doing it this particular release, I do know 
that I've been letting things slide wrt the merge window a bit too much.

So let's see how the 2.6.35 release cycle ends up looking when all is said 
and done. If pushing back harder ends up actually making things easier and 
the release cycle ends up working better as a result, I'm certainly very 
open to just being hardnosed in general.

I suspect it won't even be very painful if people just get used to it. And 
if it ends up really helping sub-maintainers ("I can't do that, because 
Linus wouldn't pull the result anyway"), then that would be a really good 
reason for me to be rather stricter about the rules.

			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/