Re: Please consider reverting7d930bc33653d5592dc386a76a38f39c2e962344

[Linus Torvalds]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/