2007/11/9, Tom K <tom@archlinux.org>:
Well, this kicked itself off in IRC this morning (timezone GMT+1), and as it seems most people didn't see it and/or didn't participate, we should probably do it here.
Here's the question, as I see it - what do we patch kernel26 for? Bugfixes? Stability? Enhancements? New features? Other?
Specific case under discussion: http://bugs.archlinux.org/task/8500 - a request, from a single user so far, for a new feature in the kernel.
We also have, or had, a request for fbsplash (closed, of course) and there are probably others - Romashka?
My understanding of The Arch Way, as it applies here, is that we patch for bugfixes e.g. ipw2x00, and for enhancements to existing functionality e.g. alsa. In the referenced bug report, there are differing dev views expressed - as I'm posting this, I'll include my view, which is that we should not add new features to kernel26.
I'll also include a possible compromise:
/me grabs big can of worms, opens it, pours it out onto DevLand :)
Two kernels - a strictly as-vanilla-as-possible kernel26 in Core, and a more let's-try-new-features-here kernel26extra in Extra. It could be in Community either, but I would see it as an official Arch package, supported by the dev team. I would be happy to maintain it if necessary, along with the usual array of external module packages - in cooperation, of course, with the current kernel maintainers.
Right now, anyone who has read the IRC log knows how Tobias P and Aaron feel about it, but I expect others have views on this topic too, so let's hear them.
Two kernels is a bad idea. Even vanilla kernel does need patches, so "as vanilla as possible" will contain same bugfixes and alsa updates as another kernel. And it does need features like squashfs/unionfs/aufs because we need them for our LiveCDs. I'm fine with that additional undervolting feature because a) it touches only small pice of code and b) our kernel maintainer is fine with it. Creating extra kernel just because of this is a bad idea. I don't want to see another flame here. However, if someone wants much more patched kernel, e.g. with Reiser4 support - this deserves for a separate kernel package. I don't know many such features though. Suspend2/TuxOnIce package died because it was hard to maintain and often broke. ck died. beyound died, vesa-tng which was one of cool features here transformed to uvesafb and will be in kernel .24. So I really see no point why very small and unintrusive patches could be maintained on our default kernel. Sure, everyone has his own opinion about what is useful. I'm fine with any small features that are not hard to maintain, doesn't make difference for those who don't need them and are unintrusive to kernel code. -- Roman Kyrylych (Роман Кирилич)