thoughts on modules-extra subpackage...

[Josh Boyer]

On Tue, Dec 06, 2011 at 05:13:46PM -0500, Andy Gospodarek wrote:
> > At the same time, we should probably be a bit more judicious about
> > enabling new drivers.  They're normally not all that great in their
> > first full release, so they should default to off until requested or
> > proven otherwise.
> > 
> 
> How are we going to know how bad they are if we do not enable them?

Could:

Watch lkml (and the other lists) for a decreasing number of reported
issues upstream.

Find users that are willing to test them out and provide useful bug
reports to upstream.  Build scratch kernels, give them steps to build
the drivers, etc.

Leverage rawhide and enable them there, but leave them off in stable
release rebases.

> I'm not saying we cannot do what you propose, I would just like to
> understand how well you expect a driver to perform before you are
> willing to enable it.

I'm not saying the above methods are perfect, but I really don't think
our current 'enable everything' mentality is helping anyone.  Take the
uas module for example.  It was enabled, and promptly provided numerous
tracebacks for users that were just trying to use their USB storage
devices that worked fine before.

I'm sure counter examples can be found where drivers work great too
(maybe the new brcm80211 ones even), but it's really kind of throwing a
dart at the moment.  I'd just like to see a bit more caution.  Nothing
comes close to distro user testing coverage, but I don't think
subjecting unsuspecting users on stable releases is really helping the
user experience.

josh