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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20081006151151.GE1380@ucw.cz>
Date:	Mon, 6 Oct 2008 17:11:51 +0200
From:	Pavel Machek <pavel@...e.cz>
To:	Randy Dunlap <randy.dunlap@...cle.com>
Cc:	Paul Mundt <lethal@...ux-sh.org>,
	Parag Warudkar <parag.lkml@...il.com>,
	Greg KH <gregkh@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Andreas Gruenbacher <agruen@...e.de>,
	Jeff Mahoney <jeffm@...e.de>
Subject: config_experimental was Re: [patch 00/04] RFC: Staging tree
	(drivers/staging)

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/