kqemu is now GPLv2

[Dave Jones]

On Wed, Feb 07, 2007 at 05:05:16PM +0100, Andreas Bierfert wrote:

 > To me the most important thing in fedora is user
 > experience and having modules for e.g. hardware available clearly is one of the
 > most basic and important things.

I'm tired of hearing this 'user experience' as an excuse for this.
What about the user experience when they hit a bug in the kernel, and can't
upgrade to a fixed version because their module doesn't work on the new one?
What about the user experience when they file bugs and the Fedora kernel
team refuses to look at them unless the module is removed (which they don't want to do?)
What about the user experience when equivalent functionality (but different/incompatible)
is merged upstream ?
What about the user experience when someone hoses their initrd, and their
system doesn't boot any more? This part of the boot process is _really_ fragile,
so some bogus module can break this unintentionally very easily.
See the disaster from FC3 era when livna shipped a horked nvidia module.
(That particular event cost me a lot of hours over ~2-3 months, chasing a bug
 that a) I couldn't fix and b) wasn't even caused by anything I did, so yes,
 I'm somewhat jaded by external modules)

improving "user experience" is not an excuse for doing this whilst people
conveniently ignore the parts that *ruin* user experience for others.

 > If the modules are free in the fedora sense
 > why should we keep our users away from them?

How about increased workload for the kernel team for one?
I don't see anyone doing much to improve *my* user experience.

 > In a sense they then still will be second
 > class fedora 'packages'

This doesn't work.  People take the attitude "You shipped it, you support it".
We had this fiasco with RHEL3 when we shipped a 'kernel-unsupported' package.

 > and I think that is a clear sign for upstream and users
 > to work on an integration to the kernel (add big red bold fancy 3D letters to
 > state this ;) ).

Or it could be seen as a clear sign "Why do I need to bother getting it
upstream, it's in the distros".  Lack of integration is a bargaining chip.
Imagine if we'd taken the same stance with Xen, maybe it'd be upstream by now.

 > Support and endorse out of tree modules to get integrated into the upstream
 > kernel and where possible support upstream to reach that goal.

'where possible' basically comes down to "magic up some extra engineers"
because unless someone with kernel knowledge is explicitly affected by it,
this won't happen.  The number of cases that this _has_ happened, has
been very low. The only one that jumps to mind is bcm43xx when dwmw2
cared about it until it got upstream, fixing it where it broke for him,
and interacting with the upstream.

 > If that is not
 > possible or not desirable for some reason try to convince people to still do it
 > but also give users a chance to use the module via our magic management tool.

I'm not a big fan of 'magic'.

		Dave

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