[<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