[fab] Kernel Module packages in Core and Extras

[Thorsten Leemhuis]

Josh Boyer schrieb:
> 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.

Nice idea. But do we have enough people with enough time to wok on it? I
doubt it a little. It maybe could work if we get kernelnewbies.org (or
something like that) involved.

[...]
>> 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...

Agreed ;-)

>  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 ;)

I'm not the one for that job in any case. Some kernel developers would
have to do that.

>> - 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.

Yes, that's the problem.

> It breaks upgrade paths, and leaves users out in the cold.

Yes.

>  For things
> like Zaptel, where there are no plans to upstream, that might effect
> lots of users.

Well, things like zaptel probably shouldn't be allowed in this scheme.

>> == 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.

Agreed. But I prefer a committee of people that know what they are doing
(e.g. kernel-developers or people that know how the kernel merge process
works) over one that only know the kernel merge process slightly.

>> - 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.

Agreed. But I got the impression that some FESCo members don't
understand in depth yet why some of us don't want modules that have no
plans to get merged upstream.

[...]
>> - 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

Well, that will create lots of trouble on a rebase from 2.6.16 to 2.6.17
or so -- I doubt davej is interested to do that work.

>> - Allow all kmodule-packages in Extras.
> This scares the crap out of me when I think about things like AWOL
> maintainers, etc.

+1

> 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.

Just FYI: I'm not a kernel developer, but I follow LKML closely due to
my work as journalist. And I've dealed with kmods and livna and
fedora.us a lot and it's a frustrating job. Modules should go upstream
as fast as possible because that's the best for everyone -- but I got
the impression that the authors of a lot of external modules often don't
know that yet.

> 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.

As always: Just my 2 cent.

CU
thl