[arch-dev-public] Kernel - vanilla vs patched?

[Thomas Bächler]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20071110/2f562553/attachment.pgp>