* Sven Luther ([EMAIL PROTECTED]) [061222 05:42]: > On Fri, Dec 22, 2006 at 12:53:09PM +0100, Marc 'HE' Brockschmidt wrote: > > maximilian attems <[EMAIL PROTECTED]> writes: > > > On Fri, Dec 22, 2006 at 11:28:29AM +0100, Marc 'HE' Brockschmidt wrote: > > >> Fix it or document it, I don't care. But the current state is not > > >> releasable. > > > we are not talking about "a" patch. > > > what you need is an backport of the 2.6.19 acpi release to 2.6.18. > > > > Read again what I wrote. I will not allow Debian to release with a > > Kernel that may damage hardware without even a notice in the release > > notes. If you are not able to fix it, note that you have provided a > > broken kernel. > > Cool, let's delay etch a couple of weeks and move to a (now released) 2.6.19 > kernel, to solve this issue.
Sven, stop this! I can remember well how you promised that moving to 2.6.18 will magically solve almost all of our issues - 6 (or more) release critical bugs against 2.6.18 don't show that this has worked so well. Please try helping us on solutions rather then breaking things again. Please try to look at it from another perspective: Consider you have bought such a laptop, and you install Debian. You have even read the release notes first. Everything works well. Until one day you notice your laptop gets too warm, and eventually even breaks because of this. On deeper research, you notice that this issue was well-known to Debian, but they refused to deal with it at all. How would you feel as a user? I think this is an unacceptable perspective. Ok, what can we do? 1. ignore the problem, 2. document it in the release notes and README.Debian of the kernel, 3. prevent the kernel running on such buggy laptops [is this possible?], 4. backport ACPI from 2.6.19, or use 2.6.19, 5. isolate a smaller fix and apply it. I personally consider options 1 and 4 to be unacceptable. Option 5 would be the best, but I have yet to see that this is possible (or rather, someone knowledgeable enough has time to do it). So, we should at least document it inside of the release notes, and README.Debian, and, if possible without being to invasive, get some check inside the kernel to print a big warning on bootup, or even refuse to work until some special parameter is used. How does this proposal sound to the kernel team? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]