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

[James]

On 11/10/07, ganja guru <ganja.guru.x64 at gmail.com> wrote:
> On Nov 9, 2007 5:58 PM, Tom K <tom at archlinux.org> wrote:
>
> > /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.
> >
>
> How would we draw the line as to what gets into the kernel26extra
> package? Do you plan to include small but well proven functionality
> patches, or will you be including experimental support for, say,
> perhaps new filesystems or new wireless drivers and so on? To
> rephrase, if kernel26extra becomes a reality, what exactly would go
> into it, and how would this be decided?

kernel26extra sounds awfully like what beyond was. I had phc,
fbsplash, tuxonice. I don't think adding an extra kernel will work,
because then we'll get the people who only want fbsplash, because
tuxonice causes them other problems or they don't like it. Thats why
we ended up with kernel26ck and kernel26suspend2 in the repos on top
of beyond. Put lightly, dumping all extras into on kernel isnt a
solution.

Lets look at this differently. To put it lightly, editing the kernel26
pkgbuild to add/remove things, can be daunting for most or annoying to
do every release. This is why they want us to do it.  Why don't we
make the kernel26 PKGBUILD a bit more adaptable/friendly?

James
-- 
iphitus // Arch Developer // iphitus.loudas.com