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

[Roman Kyrylych]

2007/11/9, Roman Kyrylych <roman.kyrylych at gmail.com>:
> 2007/11/9, Tom K <tom at 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.

oops, typo
*could not*

> 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 (Роман Кирилич)
>


-- 
Roman Kyrylych (Роман Кирилич)