[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

kernel modules in extras criteria


Some questions have come up in the recent FESCo (Fedora Extras
Steering Comittee) meeting about criteria that should be used for
approving kernel modules in extras.

The current guidelines for kernel modules can be found at:

Aside from technical guidelines there is:

"Besides rules around the packaging there is one additional *before*
you start packaging a kernel module for Fedora Extras: Open a Review
bug in http://bugzilla.redhat.com and ask FESCo via
fedora<AT>leemhuis<DOT>info for permission if this module is allowed
for Extras. This requires that you give at least the following

Name of the package

URL of the project and a tarball of the latest version


A publishable explanation from the author(s) why the module is not
merged with the mainline kernel yet and when it's planed to get
merged. You of course can ask the author to explain it directly in the
bug report.

FESCo will look at those informations on the next meeting (those are
normally every thursday) and will vote if the kernel module is
suitable for Fedora Extras. If not it will explain the reasons in the
bug report for further discussion. For example ndiswrapper is not
suitable for Fedora Extras -- yes, it is GPLed software, but it taints
the kernel and most windows drivers won't work in the Fedora Kernel
anyway due to 4K Stacks.

Why all this?

The Fedora Project wants to encourage driver developers to merge their
sources in the kernel

It easier for everyone if the modules are in the main kernel (even for
the developers -- but they often don't know that yet)

There is often a good reason why the kernel developers refuse to merge
a driver. If it's not good enough for the kernel, why should it be
good enough for Fedora?

Most modules that are maintained independently of the kernel have
licensing issues that also make it impossible to ship them in Fedora

This came up when talking about the zaptel-kmod package:
See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177583#c41

See also the sysprof kernel module review:


- Should a kernel module where the upstream has no plans of merging
with the upstream kernel be allowed in extras? (This means it could
stay around in extras forever)

- If upstream says they are going to try and merge their module, but
never does (lack of time, technical issues, no real desire to, etc),
should the module be removed after some time?

- Should there be any other criteria? (renew approval every new
release, only allow modules for 1 year and remove, etc)

Any other thoughts on this issue?


Attachment: pgpxCdbmzOOB8.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]