[fab] Kernel Module packages in Core and Extras

[Josh Boyer]

On Sat, 2006-08-19 at 15:11 +0200, Thorsten Leemhuis wrote:
> 
> Here are my 2 cent on the whole thing: Having all modules in the
> upstream kernel is a good thing (I think everybody knows this and the
> reasons for it so I won't lay them down here again). We should work
> towards this and help module authors to understand why that's a good
> thing. In and ideal world we would even help them getting their stuff
> merged upstream.

One thing I've been thinking of is a module SIG.  The SIG would help
review the module code itself in addition to the packaging of it.  That
not only helps the module authors prepare for upstream in a perhaps less
hostile environment, it also theoretically helps the quality of the
module thereby making is somewhat safer for users.  No guarantees of any
kind would be implied though.  Just an idea I've been kicking around in
my head for the past couple days.

> But the ideal world is far away and a lot of kmodule authors are quite
> slow getting their stuff merged into the linus-kernel. That's a pity,
> but that's life. We have to deal with it somehow IMHO. Other
> distributions (Suse, Ubuntu) include a lot of modules to save their
> users the mess of compiling them on their own.

Yes, this is true.  Though I think we should leave Ubuntu out of this
discussion.  They ship proprietary modules, whereas Suse has recently
pledged not to do that.

(Note that is not a slam at Unbutu.  Just different goals between the
distros.)

> So these are some of our options afaics (those solutions that I would
> prefer most are on the top of the list):
> 
> - Nearly Ideal-World-Solution: Talk to Ubuntu and Suse. Create a kernel
> module committee. Only external modules that are permitted by the
> committee get allowed in Fedora, Suse, and Ubuntu. That should only be
> the case for a small number of modules. That would increase the pressure
> on the module authors a lot to get their drivers merged in linus-kernel.

Indeed, and ideal solution.  Perhaps not very realistic though...  I
mean, Thorsten you're great at herding the cats that are FESCo, but I'm
not sure you want to add whole new groups of cats to herd ;)

> - allow kmodule-packages in Extras for a certain time period only. I'd
> say only three (maybe only two) fedora releases. In other words: A
> module gets added to devel and FC5 now; get integrated into FC6 when it
> becomes ready. Gets also integrated into FC7, but is removed directly
> after FC7 from the devel tree so it won't show up in FC8 or later.
> Removing would be a pity, but politics are sometimes hard. (Note: the
> "only allow modules for a certain time" idea came up during the kmod
> discussion, too. It was rejected, but I still think we should have one)

My biggest issue with this is what happens when the time period is up.
It breaks upgrade paths, and leaves users out in the cold.  For things
like Zaptel, where there are no plans to upstream, that might effect
lots of users.

> == here I start with the solution I wquld like to avoid (but still:
> those solutions that I would prefer most are on the top of the list) ==
> 
> - Create a special "kmodule allow committee" that has to allow modules
> for Extras; modules that have no plans to get upstream get rejected.

Ugh, yet another committee.

> - Proceed with the current layout -- FESCo has to allow modules and
> modules that have no plans to get upstram get rejected.

It has been working so far... perhaps not ideal, but working.

> - Have no kmodule-packages in Extras. That will create some trouble for
> our users and some of them will move over to other distributions because
> those have the modules and thus support more hardware out of the box. It
> would be a big drawback IMHO. It would be an additional fight on the
> list of fights we're fighting already (ntfs, mp3, java, closed-source
> drivers) where other distributions use a less-open-source approach, but
> are a lot easier to use.

I reluctantly agree.

> - Disallow kmodule-packages in Extras and only integrate some very
> important modules in the Core kernel package (like the Broadcom-WLAN
> drivers we merged in FC% or ipw2100 and ipw2200 in FC4)

I particularly dislike this one.  I prefer the one below instead.

> - Integrate all modules in the Core kernel package
> 
> - Allow all kmodule-packages in Extras.

This scares the crap out of me when I think about things like AWOL
maintainers, etc.

As you can probably tell, I'm a bit torn on the whole subject.  I play
in kernel space quite a bit and I know the pain of debugging a machine
crippling problem because someone did something bad in a driver.  So I
can certainly see where Dave and David are coming from.

However, I agree with Thorsten in that not allowing some modules is
simply too restricting for our users.  We have rules and guidelines on
which modules can get in, but it does help users.

josh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20060819/0a35fbf3/attachment.sig>