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

Neil Brown
2006-06-11T04:40:09Z

On Saturday June 10, jeff@garzik.org 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