From: "Peter T. Breuer" <ptb@it.uc3m.es>
Date: Tue, 8 Feb 2000 21:08:00 +0100 (MET)
Yes, but I think the latter is the right marketing decision. And I am
sick of patching e2fsck. I have patches for e2compr, patches for ACLs,
patches for I don't know what. It's tough to keep them all working
together. Sometimes I can't and I have to beg the maintainers of the
patches to just _stop it_ or at least use the same version of e2fsck.
But what you're suggesting simply doesn't make sense, and doesn't solve
your problems. There are patches for e2compr, patches for ACL, patches
for capability support support, and so on. This causes a combinatoric
explosion of possible combinations.
Did you want the filesystem that supports e2compr and ACLs? Just
e2compr alone? ACL's alone? E2compr and capabilities? Capabilitiy and
ACL's? There are 8 possibilities, and as we start bringing up new
combinations, there will be 16, 32, etc. So are we going to have names
like e2c-acl? e2c-acl-cap? e2-acl-cap? etc. Ridiculous!
That's why we have the compatibility bitfield in the superblock.
Note that the *reason* why most of these patches haven't been merged
into the e2fsprogs is that it's not yet 100% certain that the format
filesystem is stable yet. You have to make patches because I want to
make it 100% clear that this is beta code, and not something which is
fully supported. If it turns out that some change is needed to more
efficienctly or robustly support ACL or Capabilities, there may not be
(almost certainly will not be) backwards compatibility with the old
format. Marketing and beta don't go together.....
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:15 EST