http://bugzilla.novell.com/show_bug.cgi?id=596844
http://bugzilla.novell.com/show_bug.cgi?id=596844#c16
--- Comment #16 from Greg Kroah-Hartman
(In reply to comment #13)
Great. So our user base needs to suffer from upstream decisions, since we're not interested in adjusting the upstream kernel to our user's needs. Makes perfectly sense.
We are not interested in taking patches to our kernel that are not going to be accepted upstream as we would be responsible for maintaining them for the next 10+ years.
Let me be blunt: You're suggesting that we're taking the blame for something that doesn't work, but do not disable it even though we know it doesn't work?!?
If we disable it, what else will break?
I know we want to use only upstream supported stuff in our kernel. I didn't know that we also want to absolutely keep broken stuff for the sake of it.
How can we reliably delete a big chunk of code, and expect other machines to also work properly?
Sigh.
Again, try submitting this upstream (or the original problem), I'm sure they will work with you to resolve the issue.
Yes, and it will take several months, with additional issues popping up. At least longer than we have time. Not because upstream developers are idiots, but because debugging these issues takes enormous time and *exactly* the same hardware.
I understand, it's nothing new with kernel development. Again, work with upstream, we aren't going to take patches that are not submitted there, and at least trying to work through. That does not scale in any way, and is madness (we have learned from prior mistakes in this area.) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.