Tobias Powalowski schrieb:
The sources are documented in PKGBUILd and the things are all from stable kernel trees.
Not all of them. Can you do me a favor: Can you please reply to my first mail and comment on the patches that have been sitting in our kernel for a looong time? I really want to know why we need some hibernate fix, mactel, toshiba-bluetooth and "acpi buggy bios" patch for 3 or 4 _major_ kernel releases, while those patches should have been merged by now (if they have even been submitted). I remember talk about a patch lately, that fixed an issue but openend another (discussion took place on the bugtracker). How do you ensure this doesn't happen?
(You want to pretend this but it doesn't matter which road you drive you are never sure if it works or breaks something else, it's too complex. Also .x kernels can have issues, the perfect kernel is and will not be reality, this is what i can tell ya of doing it the last months/years)
Stability is one thing, but the work should not be completely on our backs. We should patch certain issues in our kernel, but they should be gone in the next major release, otherwise something is really wrong here!
You never know when linus or greg decides to release .x kernels. So interim patching makes sense.
Using the prepatch for 2.6.23.2 is a _very_ good idea, I just wondered where you got it from (turns out I was looking at the wrong git tree).
The particular feature request is usable and works, i tested it here and if you don't give a damn about acpi-cpufreq(which is not autoloaded at all) you are not affected at all. If this patch existed 1.5 years ago i wouldn't have needed to change the dip switches of my mainboard to undervolt.
I use acpi-cpufreq. And I have a very strong opinion about it, as I don't want it to be broken in _any_ way (I depend on it very much). While it doesn't seem to be broken here, it introduces very dangerous functionality. I don't like the idea of adding a feature that has explicitly been rejected by upstream developers. And I don't like the fact that you added it while we had an unfinished discussion about it on the bugtracker.
Using latest alsa has big benefits of supporting latest hardware and get latest fixes for the drivers and it's a seperate kernel subsystem where this works. (and sorry to say that, alsa seems to have issues everytime, thats not the fault of alsa but the fault of the vendors that use so many different types of chips and bioses)
I am not sure if this is really still necessary. Surprisingly, this has worked out well and people usually don't complain about the state of our alsa. So I am willing to go along with it. You should however document the way you are creating these alsa patches in case you are gone for a while.
Violating KISS is not the point here it has nothing to do with it, also the arch way is not offended. Telling that the majority of devs are against it, show it to me. (The loudest ones are not the majority) I always thought we trust each other in doing the work, but flaming and bikeshedding seems to be our new hobby here.
I wouldn't take this thread as an offense, but as an opportunity to rethink the way you are working things with the kernel. I think we should evaluate the old patches more often and maybe throw some away every now and then. I don't think anybody is implying that having a pure vanilla kernel is the way to go, but it would be a good thing if we could reduce the number of patches we apply to it. I know how much work is involved with a major kernel update in Arch and it is really appreciated that you do it. And I have always supported you when I could. I have always offered my opinion when I thought you did something stupid. Still, there is always room for improvement, and I will present some ideas for better management of the -ARCH kernel soon.