[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.01.0911030756310.31845@localhost.localdomain>
Date: Tue, 3 Nov 2009 08:07:33 -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 Tue, 3 Nov 2009, Linus Torvalds wrote:
>
> But it should be fixed _quickly_. In this case, I have a bisection report
> FROM TWO DAYS AGO. And I'm still kicking myself for not just reverting
> that piece-of-shit commit then, because I spent the time to look at the
> oops and the commit, and could tell that it was crap.
Btw, "two days" may not sound like a lot, but it's over five weeks since
the merge window closed - we should be close to release. And the
particular buggy commit was merged just a few days ago (Oct 29) - and it
got some bisect loving within days of being merged.
If this had all happened during the merge window, and if the patch that
got bisected was some complex one, my view of what "quickly" means would
have been very different.
But this late in the -rc game, we should encourage people to expect the
kernel to be stable. That means that if it's not stable, we should jump on
it. As soon as possible. Quite often that should mean "revert it now, so
that users don't have to see it, and then let the developers see if they
can fix it properly".
Let the _maintainers_ run the buggy kernels in order to debug them, but we
want all the _users_ to have kernels that are useful. For the last couple
of days, we've done it the wrong way around.
Linus
PS. The fix is pushed out now. But it could have been reverted on Sunday.
--
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