From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeff Garzik <jeff@garzik.org>
Subject: Re: [RFC 0/13] extents and 48bit ext3
Date: Fri, 09 Jun 2006 15:22:54 -0400
Message-ID: <4489CA8E.1030507@garzik.org>
References: <1149816055.4066.60.camel@dyn9047017069.beaverton.ibm.com>	<4488E1A4.20305@garzik.org>	<20060609083523.GQ5964@schatzie.adilger.int>	<44898EE3.6080903@garzik.org>
	<448992EB.5070405@garzik.org>	<Pine.LNX.4.64.0606090836160.5498@g5.osdl.org>	<m33beecntr.fsf@bzzz.home.net>	<Pine.LNX.4.64.0606090913390.5498@g5.osdl.org>	<Pine.LNX.4.64.0606090933130.5498@g5.osdl.org>	<20060609181020.GB5964@schatzie.adilger.int>	<Pine.LNX.4.64.0606091114270.5498@g5.osdl.org>	<m31wty9o77.fsf@bzzz.home.net>	<Pine.LNX.4.64.0606091137340.5498@g5.osdl.org>
	<m3vera6snv.fsf@bzzz.home.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: Andrew Morton <akpm@osdl.org>,
	ext2-devel <ext2-devel@lists.sourceforge.net>,
	linux-kernel@vger.kernel.org, Linus Torvalds <torvalds@osdl.org>,
	cmm@us.ibm.com, linux-fsdevel@vger.kernel.org,
	Andreas Dilger <adilger@clusterfs.com>
Return-path: <ext2-devel-bounces@lists.sourceforge.net>
To: Alex Tomas <alex@clusterfs.com>
In-Reply-To: <m3vera6snv.fsf@bzzz.home.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/ext2-devel>,
	<mailto:ext2-devel-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=ext2-devel>
List-Post: <mailto:ext2-devel@lists.sourceforge.net>
List-Help: <mailto:ext2-devel-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/ext2-devel>,
	<mailto:ext2-devel-request@lists.sourceforge.net?subject=subscribe>
Sender: ext2-devel-bounces@lists.sourceforge.net
Errors-To: ext2-devel-bounces@lists.sourceforge.net
List-Id: linux-fsdevel.vger.kernel.org

Alex Tomas wrote:
> the main reason is that ext4 would be treated as a new generation
> fs which will be used for lots of new features probably. and it
> will take long to get into production-ready state. at the same
> time, proposed patches (at least extents itself) are heavily
> tested in production and could be made available for our users
> very soon.

No -- that's a bad way to develop it, and a good way to ensure it will 
never get stable.

You want to start from a known good point, and keep it working. 
Standard iterative development model.

	Jeff