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 _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
