This patch removes the EXPERIMENTAL option and all dependencies on

EXPERIMENTAL since they are pointless.
Complete rationale:

- Many people and all distributions are currently forced to enable

  CONFIG_EXPERIMENTAL since the options for many device drivers depend

  on this option.

  I have yet to see someone not being able to install his favorite

  distribution on his computer only because the distribution did choose

  to disable all SATA drivers with dependencies on EXPERIMENTAL in their

  kernels...

- History has shown that often the dependency on EXPERIMENTAL is not

  removed when the code has proven usable.

  As an example, is our NFSv4 support really still in an

  "alpha-test phase" [1], or is it already ready for being used?

  I don't know the answer in this specific case, but I wouldn't answer

  "still in an alpha-test phase" only based on the fact that the NFSv4

  options still depend on EXPERIMENTAL.

- It might have been differently 10 years ago, but today everything that

  is available in a released kernel should also be in a usable state.
[1] quoted from the CONFIG_EXPERIMENTAL help text
Some subsystem maintainers might want to add (and maintain!) subsystem

specific options FOOBAR_EXPERIMENTAL limited to their subsystem instead.
This patch does not touch "EXPERIMENTAL" strings in prompts - there was

anyway no strong relation in any direction between prompts claiming an

option was experimental and actual dependencies on EXPERIMENTAL...
For avoiding clashes with other patches, this patch temporarily makes

CONFIG_EXPERIMENTAL available as always enabled option.
---
This patch has been sent on:

- 11 Dec 2007

- 25 Nov 2007

- 17 Nov 2007
 Documentation/DocBook/kernel-hacking.tmpl |    7 --

 Documentation/lguest/lguest.txt           |    4 -

 arch/alpha/Kconfig                        |    1

 arch/arm/Kconfig                          |   10 +--

 arch/frv/Kconfig                          |    1

 arch/ia64/Kconfig                         |    6 +-

 arch/m68...
[ message continues ]

On Tue, Jan 01, 2008 at 03:48:09PM +0200, Adrian Bunk wrote:
Definately NAK for the MIPS segments.  Some of the EXPERIMENTAL

dependencies should be removed but many options tagged with EXPERIMENTAL

are still dangerous.
  Ralf

--

On Tue, 1 Jan 2008 15:48:09 +0200
NAK
Experimental is an important guide to driver and code quality. 
"It might have been differently 10 years ago, but today everything that

 is available in a released kernel should also be in a usable state."
So why not drop it instead. It clearly has no consensus

--

History has shown that EXPERIMENTAL tags in many areas of the kernel

have not been maintained in a way that they would be usable as a guide.
And as soon as you need _one_ driver or feature depending on

EXPERIMENTAL, you anyway lose all benefits it might have had.
The latter is the point where it makes sense if a user or distribution

e.g. enables CONFIG_ATA_EXPERIMENTAL for getting all hardware supported

but not CONFIG_CRYPTO_EXPERIMENTAL because he doesn't want to use

(resp. support usage of) experimental cryptographic algorithm 
That's not about consensus, it's more that the number of submissions

required until Andrew includes a patch into -mm seems to be related to

the number of files touched...
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

On Tue, 1 Jan 2008 17:17:51 +0200
Repeatedly posting crud does not make it right. As far as I can see the

tags are pretty honest for the most part - some have been experimental
It should be.
Alan

--

So smbfs is still considered rock solid while no serious distribution

would be crazy enough to ship the EXPERIMENTAL NFSv4 support to their

customers?
I'm not claiming that all EXPERIMENTAL tags were wrong [1], but many

were wrong.
Plus the fact that CONFIG_EXPERIMENTAL controlled so many different

things with one switch that CONFIG_EXPERIMENTAL=n .config's are really 
You removed the context.
The fact that Andrew has not applied a three times sent patch does not

necessarily imply there was any problem with a patch - "no answer" on 
cu

Adrian
[1] after all, even with a random distribution many of them

    were right  ;-)
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

Thats a different problem. The kernel as I've said many times has no

proper process for
- removing expired/missing maintainers

- handling stuff that decays

- removing dead documentation

- removing dead drivers and ports
Agreed

--

It's also the other way around:

Is e.g. NFSv4 support really still experimental?
There are only few parts of the kernel where the EXPERIMENTAL tags are

actually maintained, but most of them were simply added once and stayed

forever. If my "remove all EXPERIMENTAL tags" approach is not considered

the best solution I have no problem with starting with "convert

EXPERIMENTAL to FOO_EXPERIMENTAL in all areas where the subsystem

maintainer wants to do so" and remove the remaining EXPERIMENTAL tags 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

CONFIG_EXPERIMENTAL is way to coarse. I always need to turn it on and

then it loses any value.
Why not encode the drivers status into the driver name so that is is

obvious when you are configuring the kernel?
Like this for a driver name:

   Compaq Smart Array 5xxx support (experimental)
Some drivers are already do this:

   Micro Memory MM5415 Battery Backed RAM support (EXPERIMENTAL)
Now the status is obvious on an item by item basis.
--

Jon Smirl

jonsmirl@gmail.com

--

agreed. CONFIG_BROKEN has real use - but CONFIG_EXPERIMENTAL is pretty

pointless in the 90-days kernel development model.
Acked-by: Ingo Molnar <mingo@elte.hu>
	Ingo

--

On Tue, 1 Jan 2008 15:26:23 +0100
Then I need a replacement equivalent for the ATA layer and all the other

drivers using it to indicate stuff that *IS* experimental, or not yet

known to be highly robust. Drivers are not the same as core code Ingo and

the world driver writers live in is very different to the one you operate

in as is clearly shown by this and by the _p discussion.
Still NAK.  As the alternative is
CONFIG_ATA_EXPERIMENTAL, CONFIG_NET_EXPERIMENTAL,

CONFIG_VIDEO_EXPERIMENTAL, ... all being added by developers
We will also need experimental badly in future when the EU liability

rules (and probably the US ones in a similar time scale) change so that

liability applies to software, because then it will be very important to

clearly label code that is experimental or development code as such.
Alan

--

Yes please.
menuconfig actually supports placing config options in more than one

place, would this be helpful? (besides the itch that it is defined in

two places.)
---

 drivers/ata/Kconfig |    5 +++++

 init/Kconfig        |    8 ++++++++

 2 files changed, 13 insertions(+)
Index: linux-2.6_nosov/drivers/ata/Kconfig

===================================================================

--- linux-2.6_nosov.orig/drivers/ata/Kconfig

+++ linux-2.6_nosov/drivers/ata/Kconfig

@@ -23,6 +23,11 @@ menuconfig ATA
 if ATA
+# also see init/Kconfig

+config ATA_EXPERIMENTAL

+	bool "Prompt for experimental libata drivers"

+	depends on EXPERIMENTAL

+

 config ATA_NONSTANDARD

        bool

        default n

Index: linux-2.6_nosov/init/Kconfig

===================================================================

--- linux-2.6_nosov.orig/init/Kconfig

+++ linux-2.6_nosov/init/Kconfig

@@ -40,6 +40,14 @@ config EXPERIMENTAL

 	  you say Y here, you will be offered the choice of using features or

 	  drivers that are currently considered to be in the alpha-test phase.
+if EXPERIMENTAL

+

+# also see drivers/ata/Kconfig

+config ATA_EXPERIMENTAL

+	bool "Prompt for experimental libata drivers"

+

+endif # EXPERIMENTAL

+

 config BROKEN

 	bool
--

yeah, i'd prefer that. People might be willing to enable an experimental

video driver but not an experimental ATA driver. This global-scope "all

or nothing" CONFIG_EXPERIMENTAL is totally pointless and _no_ distro

uses it in practice.
If it's a pure label via which you want to document things as

experimental then i'd agree with adding the "Warning: experimental code"

to the help section of all the affected Kconfig entries (that way people

would be more likely to actually read that label.)
but i think your suggestion of per-subsystem and/or per-driver quality

levels is superior to that.
	Ingo

--

But this alternative is actually _better_.
The point is that e.g. a user having to enable CONFIG_ATA_EXPERIMENTAL

for getting his hardware supported does not necessarily want to see

options for experimental congestion control algorithms that might be 
Whatever that will imply for free software projects is something

completely different from what our current CONFIG_EXPERIMENTAL
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--