Stable/devel policy - was Re: [Ext2-devel] [RFC 0/13] extents and 48bit ext3

On Saturday June 10, [email protected] wrote:
> Theodore Tso wrote:
> > 	So you you would be in OK of a model where we copy fs/ext3 to
> > "fs/ext4", and do development there which would merged rapidly into
> > mainline so that people who want to participate in testing can use
> > ext3dev, while people who want stability can use ext3 --- and at some
> > point, we remove the old ext3 entirely and let fs/ext4 register itself
> > as both the ext3 and ext4 filesystem, and at some point in the future,
> > remove the ext3 name entirely?
> 
> Yep, and in addition I would argue that you can take the opportunity to 
> make ext4 default to extents-enabled, and some similar behavior changes 
> (dir_index default?).  The existence of both ext3 and ext4 means you can 
> be more aggressive in turning on stuff, IMO.
> 
> 	Jeff

I'm wondering what all this has to say about general principles of
sub-project development with the Linux kernel.

There is a strong tradition of software projects having a 'stable'
branch and a 'development' branch, and having both available and both
receiving bug fixes (at least) so that users can choose what best
suits their needs.

Due to the (quite appropriate) lack of a stable API for kernel
modules, it isn't really practical (and definitely isn't encouraged)
to distribute kernel-modules separately.  This seems to suggest that
if we want a 'stable' and a 'devel' branch of a project, both branches
need to be distributed as part of the same kernel tree.

Apart from ext2/3 - and maybe reiserfs - there doesn't seem to be much
evidence of this happening.  Why is that?

 - is -mm enough?  It seems to be enough for small updates, but
   doesn't seem to be enough for more major projects.  How long
   have the ext3 patches been in -mm?? (I cannot actually seem
   to find them there at all)

 - is there lots of -devel code slipping in to the 'stable' tree, thus
   resulting in a kernel.org tree that is permanently unstable (in
   which case there should be no objection to the new ext3 code -
   leave it to distros to keep it out until it is stable).

 - are we just not innovating as much as we could be and so don't
   need a -devel? Is ext3 the only site of major innovation?
   Seems unlikely.

It seems a bit rough to insist that the ext-fs fork every so-often,
but not impose similar requirements on other sections of code.

So: what would you (collectively) suggest should be the policy for
managing substantial innovation within Linux subsystems?  And how
broadly should it be applied?

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html