From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Brown Subject: Stable/devel policy - was Re: [Ext2-devel] [RFC 0/13] extents and 48bit ext3 Date: Sun, 11 Jun 2006 14:39:37 +1000 Message-ID: <17547.40585.982575.7069@cse.unsw.edu.au> References: <20060609181020.GB5964@schatzie.adilger.int> <4489C580.7080001@garzik.org> <17D07BC0-4B41-4981-80F5-7AAEC0BB6CC8@mac.com> <20060610212624.GD6641@thunk.org> <448B45ED.1040209@garzik.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Theodore Tso , Linus Torvalds , Kyle Moffett , Chase Venters , Alex Tomas , Andreas Dilger , Andrew Morton , ext2-devel , linux-kernel@vger.kernel.org, cmm@us.ibm.com, linux-fsdevel@vger.kernel.org Return-path: Received: from ns2.suse.de ([195.135.220.15]:10954 "EHLO mx2.suse.de") by vger.kernel.org with ESMTP id S1161078AbWFKEkG (ORCPT ); Sun, 11 Jun 2006 00:40:06 -0400 To: Jeff Garzik In-Reply-To: message from Jeff Garzik on Saturday June 10 Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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