Enabling drivers in staging tree in rawhide

Dave Jones davej at redhat.com
Thu Jan 8 15:35:42 UTC 2009

On Thu, Jan 08, 2009 at 07:17:30AM +0100, Thorsten Leemhuis wrote:

 > Related: I raised the staging problem already in
 > https://bugzilla.redhat.com/show_bug.cgi?id=477927
 > as rawhide contained the at76 driver as separate patch
 > http://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/linux-2.6-at76.patch?view=markup
 > -- but the same driver (with two small changes) also was part of the 
 > upstream kernel since October/2.6.28-rc as one of the staging drivers:
 > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99e06e372378c5833a0c60274b645dfb2e4a4b08
 > (for more details see bug).
 > That sounds wrong to me, as
 > - it's duplicated work
 > - the at76 staging driver from upstream taints the kernel; the driver 
 > from our patch doesn't.

The wireless stuff, I've pretty much deferred to the wireless maintainer, John Linville.
I don't know the backstory behind at76, but it's been lingering for
quite a while, and it would be nice to see it go away yes.
I'm not clear on why this is going through -staging instead of wireless-dev either.
 > > The ralink wireless drivers for example would hopefully make the newer 
 > > EEE PC model would out of the box.  Does it make sense to enable the 
 > > drivers in staging tree by default and bring more exposure to them 
 > > atleast via rawhide if not in general releases?
 > +1 to the "I think providing hardware support in rawhide and then 
 > removing it  before release would be somewhat user-hostile." comment 
 > from mjg59.
 > IOW: Either enable or disable them. I'm unsure myself what to do but I 
 > tend to say that disabling the whole staging drivers might be the best 
 > for Fedora (Greg calls himself as "maintainer of crap" for a good reason).
 > @Davej, Cebbert and Kylem: What's your position on this?

I don't think we can make a carte-blanche statement to say "no we won't do this ever".
The quality of the drivers that end up there are going to vary, and for some,
if it's for a piece of hardware that's really popular, it may make sense
to enable it.  As long as doing so doesn't cause us headaches down the line.

I'm not overly against the idea of enabling something with the caveat
that we have someone responsible for working on it, with the goal of
getting it out of staging, and dealing with bugs etc.
Not unlike the same reasoning for us adding various not-yet-upstream drivers
to the Fedora kernel really.

But it's really going to be a case-by-case thing I think. 



More information about the fedora-devel-list mailing list