[OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule

[Simon Wilkinson]

On 17 Jun 2010, at 21:40, Russ Allbery wrote:
>=20
> There is that.  I intend to ship with DAFS enabled for Debian, but the
> Debian packages have always taken a fairly aggressive approach to =
enabling
> features.  (They have had supergroups enabled for quite some time, for
> example, and also enable UNIX domain sockets for fssync, and I intend =
to
> enable disconnected as well.)

This is one of the many problems with having too many knobs that can be =
twiddled. There is no longer "OpenAFS" - you end up with "Debian's build =
of OpenAFS" which behaves in a completely different way to
"the RPMS on the OpenAFS website", which use completely different paths =
from "the RPMFusion RPMS", which behave differently again to "the =
Solaris tarball" and so on. If you're a new user to OpenAFS, how on =
earth do you work out which set of settings you should be using? Do you =
know that you're using the Demand Attach Fileserver, or whether your =
package is build with Transarc paths, or what the difference between =
inode and namei is? At some point, you'll just give up in disgust.

I'd really like us to standardise on a _small_ (ideally one) set of =
supported configurations which we suggest for each release - and for the =
binary packages that we point users at to use that set of configurations =
across all platforms. It's the only way that we're ever going to manage =
to produce a coherent documentation set, to provide meaningful advice on =
lists and in chatrooms, and in general, retain our sanity.

If we believe the demand attach is ready then, IMO, it shouldn't be =
hidden behind a configuration switch. If it is, I doubt it will see much =
more use than it does at present. My current feeling is that it would be =
great if we could ship both fileservers, side by side, with different =
executable names - but I haven't looked at any of the code to see how =
complex this would be to achieve.

Cheers,

Simon.