Re: [PATCH 1/5] Forking ext4 filesystem from ext3 filesystem

Jeff Garzik <[email protected]> Thu, 10 Aug 2006 16:52:49 -0400
Newsgroups gmane.linux.file-systems,gmane.linux.kernel,gmane.comp.file-systems.ext2.devel
Message-ID <[email protected]>
Andrew Morton wrote:
> On Thu, 10 Aug 2006 16:22:26 -0400
> Jeff Garzik <[email protected]> wrote:
> 
>> I strongly disagree that ext3 should be subject to a spring cleaning. 
>> Comments, whitespace, very very minor things, sure.  Trying to get rid 
>> of brelse() when _many_ other filesystems also use it?  ext4 material.
> 
> We should seek to minimise the difficulty of cross-porting bugfixes and
> enhancements.  Putting cleanups in only ext4 works against that.
> 
> ext3 will be around for many years yet.  We cannot just let it rot due to
> some false belief that performing routine maintenance against it will for
> some magical reason cause it to break.

Because ext4 is impending, you want to push a bunch of cleanups into 
ext3 over a short span of time.  That's not routine maintenance at all. 
  We're not talking about routine maintenance.  In your words, we are 
talking about spring cleaning.

Why not let the devel/stable system work its magic?  If the cleanups are 
viable, proving that first in ext4 should give us more confidence to put 
them into ext3.

Cross-porting bugfixes and cleanups will _obviously_ be quite easy, 
during the first few months of ext4's life.

Just look at ext2->ext3 history.  Regardless of when you make the split, 
there will be a bunch of stuff people wish to backport after the split 
occurs.  Given that, it makes more sense to testbed the changes in ext4 
first.

	Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html