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.2.01.0911030815180.31845@localhost.localdomain>
Date:	Tue, 3 Nov 2009 08:23:38 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Marcel Holtmann <marcel@...tmann.org>
cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	David Miller <davem@...emloft.net>, johannes@...solutions.net,
	linville@...driver.com, linux-kernel@...r.kernel.org,
	linux-wireless@...r.kernel.org
Subject: Re: Please consider reverting
 7d930bc33653d5592dc386a76a38f39c2e962344



On Wed, 4 Nov 2009, Marcel Holtmann wrote:
>
> I do have a patch in my inbox from Johannes from 4 days ago that fixes
> this issue.
> 
> 	http://marc.info/?l=linux-wireless&m=125697124819563&w=2
> 
> So what is the take away from this now? Do you wanna have Johannes step
> over John and Dave and send such a patch directly to you?

Hell yes. If it causes lockups for people, and the original commit is 
_known_ to be buggy, these kinds of things should be expedited.

How much users time and effort do we want to waste?

And there's a secondary issue too - how comfortable do we want people to 
be to test late-in-the-game -git trees? I should hope that they should be 
considered pretty stable. And ask yourself: would it have been better to 
have had this bug in my -git tree for just one day, or for five days?

Of course, the optimal situation would have been that such a buggy commit 
wouldn't have been ever merged in the first place - at least not after 
-rc5. But notice how I'm not really complaining about that part: I'm a 
firm believer in the "bugs happen" reality, and while we should try to be 
careful, things like this _will_ slip through. 

So I'm not unhappy about the bug happening in the first place. It would 
have been better had it not, but hey, mistakes happen. We should just 
"Deal with it". 

And yes, "dealing with it" very much means by-passing maintainers if 
necessary. It can mean sending patches directly to me, but it _also_ means 
asking me to just revert a commit that turns out to be buggy and was 
merged late.

And that's what I'm really arguing for here - I don't like how you and 
Johannes were arguing against "dealing with it". As it was, we clearly had 
users wasting their time on this.

		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

Powered by Openwall GNU/*/Linux Powered by OpenVZ