[2.6.24 patch] let EXT4DEV_FS depend on BROKEN

[2.6.24 patch] let EXT4DEV_FS depend on BROKEN

[Adrian Bunk]

It might make sense to offer ext4 in -mm and even in early -rc kernels, 
but I've already seen people using ext4 simply because a stable kernel 
offered it - and that's definitely not intended.

Anyone who _really_ wants to test ext4 should anyway be able to do the 
trivial change of removing the "depends on BROKEN" line.

Signed-off-by: Adrian Bunk <bunk@kernel.org>

---
f778e1d046a3554ca15b8637afd0ffbf4790801c 
diff --git a/fs/Kconfig b/fs/Kconfig
index 487236c..d850725 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -138,7 +138,7 @@ config EXT3_FS_SECURITY
 
 config EXT4DEV_FS
 	tristate "Ext4dev/ext4 extended fs support development (EXPERIMENTAL)"
-	depends on EXPERIMENTAL
+	depends on BROKEN
 	select JBD2
 	select CRC16
 	help

Re: [2.6.24 patch] let EXT4DEV_FS depend on BROKEN

[Andreas Dilger]

On Jan 02, 2008  03:32 +0200, Adrian Bunk wrote:
> It might make sense to offer ext4 in -mm and even in early -rc kernels, 
> but I've already seen people using ext4 simply because a stable kernel 
> offered it - and that's definitely not intended.
> 
> Anyone who _really_ wants to test ext4 should anyway be able to do the 
> trivial change of removing the "depends on BROKEN" line.
> 
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
> 
> @@ -138,7 +138,7 @@ config EXT3_FS_SECURITY
>  
>  config EXT4DEV_FS
>  	tristate "Ext4dev/ext4 extended fs support development (EXPERIMENTAL)"
> -	depends on EXPERIMENTAL
> +	depends on BROKEN
>  	select JBD2
>  	select CRC16
>  	help

Isn't CONFIG_EXPERIMENTAL enough?

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

Re: [2.6.24 patch] let EXT4DEV_FS depend on BROKEN

[Adrian Bunk]

On Wed, Jan 02, 2008 at 10:41:57AM -0700, Andreas Dilger wrote:
> On Jan 02, 2008  03:32 +0200, Adrian Bunk wrote:
> > It might make sense to offer ext4 in -mm and even in early -rc kernels, 
> > but I've already seen people using ext4 simply because a stable kernel 
> > offered it - and that's definitely not intended.
> > 
> > Anyone who _really_ wants to test ext4 should anyway be able to do the 
> > trivial change of removing the "depends on BROKEN" line.
> > 
> > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> > 
> > @@ -138,7 +138,7 @@ config EXT3_FS_SECURITY
> >  
> >  config EXT4DEV_FS
> >  	tristate "Ext4dev/ext4 extended fs support development (EXPERIMENTAL)"
> > -	depends on EXPERIMENTAL
> > +	depends on BROKEN
> >  	select JBD2
> >  	select CRC16
> >  	help
> 
> Isn't CONFIG_EXPERIMENTAL enough?

Most people and all distributions use CONFIG_EXPERIMENTAL=y simply 
because too many options (including options required for hardware 
support) depend on it.

Compare e.g.:
- "Marvell SATA support (HIGHLY EXPERIMENTAL)"
- "Provide NFSv4 client support (EXPERIMENTAL)"
- "Ext4dev/ext4 extended fs support development (EXPERIMENTAL)"

And I really do not have the impression that ext4 is ready for being 
used by people who cannot remove this depends line from a Kconfig file
in their kernel.

> Cheers, Andreas

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

Re: [2.6.24 patch] let EXT4DEV_FS depend on BROKEN

[Eric Anopolsky]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

> > Isn't CONFIG_EXPERIMENTAL enough?
> 
> Most people and all distributions use CONFIG_EXPERIMENTAL=y simply 
> because too many options (including options required for hardware 
> support) depend on it.

Maybe I'm wrong, but I think most people use the distro-provided
precompiled kernels. This is only a danger to people who insist on
compiling their own kernels but who don't know enough to investigate
things labeled "EXPERIMENTAL" before typing Y.

IMHO, these people are a dying breed since modern distros seem to do a
good job at preventing problems that drive ordinary users to compile
their own kernels in the first place. IMHO, it's reasonable to expect
the small minority of Linux users who want to compile their own kernels
to learn that "EXPERIMENTAL" means something.

Cheers,
Eric


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.6.24 patch] let EXT4DEV_FS depend on BROKEN

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 421 bytes --]

On Wed, 02 Jan 2008 13:51:32 PST, Eric Anopolsky said:

> their own kernels in the first place. IMHO, it's reasonable to expect
> the small minority of Linux users who want to compile their own kernels
> to learn that "EXPERIMENTAL" means something.

And what, exactly, does it mean, given that there's a bunch of stuff that's
tagged EXPERIMENTAL that's more solid/tested than a lot of stuff that *isn't*
marked with it?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [2.6.24 patch] let EXT4DEV_FS depend on BROKEN

[Eric Sandeen]

Adrian Bunk wrote:
> Most people and all distributions use CONFIG_EXPERIMENTAL=y simply 
> because too many options (including options required for hardware 
> support) depend on it.
> 
> Compare e.g.:
> - "Marvell SATA support (HIGHLY EXPERIMENTAL)"
> - "Provide NFSv4 client support (EXPERIMENTAL)"
> - "Ext4dev/ext4 extended fs support development (EXPERIMENTAL)"

       tristate "Snapshot target (EXPERIMENTAL)"
       depends on BLK_DEV_DM && EXPERIMENTAL

       tristate "Mirror target (EXPERIMENTAL)"
       depends on BLK_DEV_DM && EXPERIMENTAL

...

It does seem that it might be a good goal to revisit options marked
EXPERIMENTAL, and see if they still should be marked as such, rather
than removing the option altogether.

init/Kconfig describes things in "EXPERIMENTAL" as "alpha-test" - I bet
there are a few things which have moved beyond this, but are still
marked as such.

-Eric

Re: [2.6.24 patch] let EXT4DEV_FS depend on BROKEN

[Alan Cox]

On Wed, 2 Jan 2008 10:41:57 -0700
Andreas Dilger <adilger@sun.com> wrote:

> On Jan 02, 2008  03:32 +0200, Adrian Bunk wrote:
> > It might make sense to offer ext4 in -mm and even in early -rc kernels, 
> > but I've already seen people using ext4 simply because a stable kernel 
> > offered it - and that's definitely not intended.
> > 
> > Anyone who _really_ wants to test ext4 should anyway be able to do the 
> > trivial change of removing the "depends on BROKEN" line.
> > 
> > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> > 
> > @@ -138,7 +138,7 @@ config EXT3_FS_SECURITY
> >  
> >  config EXT4DEV_FS
> >  	tristate "Ext4dev/ext4 extended fs support development (EXPERIMENTAL)"
> > -	depends on EXPERIMENTAL
> > +	depends on BROKEN
> >  	select JBD2
> >  	select CRC16
> >  	help
> 
> Isn't CONFIG_EXPERIMENTAL enough?

Of course it is - Adrian is however trying to remove CONFIG_EXPERIMENTAL
and reality is getting in his way again 

Re: [2.6.24 patch] let EXT4DEV_FS depend on BROKEN

[Diego Calleja]

El Wed, 2 Jan 2008 03:32:18 +0200, Adrian Bunk <bunk@kernel.org> escribió:

> It might make sense to offer ext4 in -mm and even in early -rc kernels, 
> but I've already seen people using ext4 simply because a stable kernel 
> offered it - and that's definitely not intended.

But isn't that the whole purpose of having ext4 snapshots in the stable kernel - to
allow people to try it?

Re: [2.6.24 patch] let EXT4DEV_FS depend on BROKEN

[Adrian Bunk]

On Wed, Jan 02, 2008 at 07:26:29PM +0100, Diego Calleja wrote:
> El Wed, 2 Jan 2008 03:32:18 +0200, Adrian Bunk <bunk@kernel.org> escribió:
> 
> > It might make sense to offer ext4 in -mm and even in early -rc kernels, 
> > but I've already seen people using ext4 simply because a stable kernel 
> > offered it - and that's definitely not intended.
> 
> But isn't that the whole purpose of having ext4 snapshots in the stable kernel - to
> allow people to try it?

ext4 has quite an unusual development model for kernel code, other 
code in the state of ext4 is usually only in -mm and not in stable 
kernels.

Stable kernels are mainly meant for usage, not for trying stuff.
And although I see a point in perhaps shipping some not-yet-perfect 
device drivers for otherwise unsupported hardware or some
not-yet-perfect filesystems required for accessing foreign
(non-Linux) filesystems, I don't see any point in offering a
WIP Linux-only filesystem in stable kernels.

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

Re: [2.6.24 patch] let EXT4DEV_FS depend on BROKEN

[Alan Cox]

> Stable kernels are mainly meant for usage, not for trying stuff.

You appear to be reinventing history in your attempt to justify removing
CONFIG_EXPERIMENTAL.

> And although I see a point in perhaps shipping some not-yet-perfect 
> device drivers for otherwise unsupported hardware or some
> not-yet-perfect filesystems required for accessing foreign
> (non-Linux) filesystems, I don't see any point in offering a
> WIP Linux-only filesystem in stable kernels.

So that people can use it and test it. Most people don't run -mm or GIT.

Alan

Re: [2.6.24 patch] let EXT4DEV_FS depend on BROKEN

[Trond Myklebust]

On Wed, 2008-01-02 at 23:16 +0200, Adrian Bunk wrote:
> On Wed, Jan 02, 2008 at 07:26:29PM +0100, Diego Calleja wrote:
> > El Wed, 2 Jan 2008 03:32:18 +0200, Adrian Bunk <bunk@kernel.org> escribió:
> > 
> > > It might make sense to offer ext4 in -mm and even in early -rc kernels, 
> > > but I've already seen people using ext4 simply because a stable kernel 
> > > offered it - and that's definitely not intended.
> > 
> > But isn't that the whole purpose of having ext4 snapshots in the stable kernel - to
> > allow people to try it?
> 
> ext4 has quite an unusual development model for kernel code, other 
> code in the state of ext4 is usually only in -mm and not in stable 
> kernels.

Bullshit... We all do this.

> Stable kernels are mainly meant for usage, not for trying stuff.
> And although I see a point in perhaps shipping some not-yet-perfect 
> device drivers for otherwise unsupported hardware or some
> not-yet-perfect filesystems required for accessing foreign
> (non-Linux) filesystems, I don't see any point in offering a
> WIP Linux-only filesystem in stable kernels.

This breaks with the 2.6.x development model that we've been working
with for several years now. I, for one, do not wish to change that
model.

Trond