config_experimental was Re: [patch 00/04] RFC: Staging tree(drivers/staging)

[Pavel Machek]

Hi!

> > > > How? TAINT_EXPERIMENTAL (I'll stick to that, thanks :) and
> > > > CONFIG_EXPERIMENTAL are no different - neither to users nor to
> > > > developers. Here is why -
> > > > Both try to do the same thing - let people use the drivers on their
> > > > own risk (as if the stable ones are developer's risk - but let's keep
> > > > it aside for the moment) and give developers a chance to keep the code
> > > > in sync with mainline and improve it per user problem reports or
> > > > generally make it better.
> > > > 
> > > Uhm.. not quite. As the one that proposed the flag in the first place,
> > > perhaps it helps to cover the rationale (although Greg seems to have
> > > mostly covered that already).
> > > 
> > > EXPERIMENTAL today is pretty damn meaningless. What it tends to mean in
> > 
> > then it would be better if Greg/someone cleaned up the current tree's
> > problems instead of introducing more CRAP under a different name.
> > Oh well, his mind is already made up and I know how difficult it is to
> > change it.
> 
> I shouldn't have said that last sentence.  I apologize to Greg.
> 
> ISTM that the real problems are (a) it's easier to introduce new staging/crap
> than it is to fix EXPERIMENTAL and (b) no one wants to try to fix EXPERIMENTAL.
> 

I do believe that staging != experimental.

experimental == 'good enough code architecture-wise, needs more
testing, coding style is ok'

staging == 'don't look at this after lunch' (at least parts are bad).

Now... I guess someone could go over supported drivers in enterprise
distro, and remove experimental from all of them in mainline...?
Distros pay some attetion to what code they are willing to support...

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/