On Saturday June 10, jeff@xxxxxxxxxx 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
