Re: [GIT PULL] Squashfs pull request for 2.6.29

[Ingo Molnar <mingo@elte.hu>]

* Greg KH <gregkh@suse.de> wrote:

> > I don't mean to piss on your parade, but from my viewpoint, staging is 
> > a trainwreck so far, and I'd hate to see it get worse.
> 
> What is wrong with it?  Bugs are getting fixed, people are getting use 
> out of their hardware (hell, Linus is even using one of the drivers), 
> and lots of developers are cutting their teeth on helping out.
> 
> If you don't like it, just disable it in your kernel packages, or 
> instantly close out the bugs.  The drivers in staging has already helped 
> out some distros by virtue of including newer drivers than they were 
> mistakenly using at the time (Ubuntu, I'm looking at you...)
> 
> And again, it's helped out users, which is the most important thing 
> here.

yes.

Firstly, a distro can disable CONFIG_STAGING just fine and then there will 
be no 'crappy' drivers in that distro.

The thing is, the past decade has taught us that distros are willing to 
apply just about any crap if it helps out a significant proportion of 
users. Utrace crashes in Fedora dominated kerneloops.org stats for months. 
Special ACPI patches and hacks, experimental wireless and DRI drivers in 
Fedora, etc.

Why should the mainline kernel be any different? Treating it differently 
would be a double standard. If a distro can apply crappy patches in sake 
of utility, why shouldnt the upstream kernel have a staging area where 
useful but not fully upstream-worthy drivers can hang around?

For years the upstream kernel was a lot less useful to testers in practice 
because all the crappy but useful patches were in the distro kernels but 
not in the mainline kernel.

Now that the upstream kernel has such an area, exactly what has changed - 
besides making the kernel more useful, more testable, more hackable and 
more viable? In fact i claim that crap gets cleaned up much faster if it's 
out in the open for all to see - instead of hidden in distro SRPMs.

	Ingo