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