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 _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board _______________________________________________ fedora-advisory-board-readonly mailing list fedora-advisory-board-readonly@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly
