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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
