kernels in the packaging universe (was: Re: F7 Plan (draft))

[Dave Jones]

On Wed, Dec 20, 2006 at 04:21:35PM +0100, Thorsten Leemhuis wrote:
 
 > Well, I was against kernels in Extras in the past, too, and I agree that
 > maintaining them would be a large maintenance headache. But I more and
 > more think we should have a (semi-)official place for alternate
 > kernel-images (say RT, OpenVZ, OLPC, PS3, Vserver, Xen, Vanilla [would
 > be cool for debugging bugs to check if they are fedora-specific], mm,
 > latest-linus,...) in Fedora-land somewhere with a big, fat warning sign:
 > - Use at your own risk
 > - no guarantees for security updates

This alone should be enough to be a nail in this coffin.
We have a really good track record for security updates in Fedora, despite
it being advertised that its going to be a best-effort attempt, no guarantees,
yadayada..  This would be a huge step backwards.

 > - be aware that these kernels might miss features like Xen, tux, foo or
 > bar that are in the main kernel package
 > - no precompiled kmods are available

You can add all the warning signs you want, but there's a fatal flaw.

                    PEOPLE DON'T FSCKING READ THEM.

kernel.org bugzilla has this when you try to file a new bug..

"NO BINARY MODULES or other tainted kernels. Do not file bugs here if you have
 any binary kernel modules loaded, reproduce without that module first.
 NVIDIA users - THIS MEANS YOU!"

Guess how many bug reports get filed there tainted with nvidia.ko ?

And this was just the most recent example that popped into my head.

For a Fedora specific example:
We get no end of requests to add driver xyz to the kernel, regardless
of how many times we state our "upstream first" policy.

To go through the examples you gave:

RT : This needs to be upstream. And bits of it are going that way all
     the time.
OpenVZ: Needs to go upstream. These folks have been somewhat quiet of late.
OLPC: This is already available somewhere on laptop.org, and being in
  extras isn't really of any value to people not running an olpc.
PS3: The PPC64 kernel will support this out of the box.
VServer: upstream.
Xen: Needs a bullet in the head.
Vanilla: Probably the only alternative kernel that actually makes sense.
mm: Seriously bad idea. Seriously. Bad. Idea.  The last one ate peoples
 data. We cannot allow things like this into extras, even as an experiment,
 even with a gazillion warnings that people will ignore.


Merging something into a vendor kernel is a *commitment* to the end
user that you will continue to provide this feature, and that you will
be responsive in fixing any problems that may arise.

Just keeping things working is a *lot* of work.   I'm currently
overwhelmed trying to get Tux, signed modules and Xen working again
in rawhide.  To the point I've given up and have asked for others help
in getting them back on track.  Hows this going to work out for
extras packages when the packager can't get it together?

Based upon the majority of bugs I've encountered in extras packages,
I have next to zero faith that anything will be done about bugs that
get filed against extras-kernels, eventually ending up with
"Oh I know, I'll bug the Fedora kernel maintainers".

		Dave

-- 
http://www.codemonkey.org.uk