[OpenAFS-devel] Selecting a configuration file format for OpenAFS Services

[Matt W. Benjamin]

Hi,

Yes, supporting ~forever is unsupportable.

But I don't know, but what if we said, ok from here on, options not getting=
 special dispensation are 'subject to migration,' to reappear in the config=
 file.  Only options promoted to unmarked would be around ~forever, and, ev=
en then, create another marked state where options are subject to move at a=
 finite date some time in the future.  I mean, let's find some flexibility =
somewhere, somehow...

Matt

----- Original Message -----
From: "Derrick Brashear" <shadow@gmail.com>
To: "Matt W. Benjamin" <matt@linuxbox.com>
Cc: "OpenAFS Devel" <openafs-devel@openafs.org>, "openafs" <openafs-info@op=
enafs.org>
Sent: Saturday, May 16, 2009 11:21:55 AM GMT -05:00 US/Canada Eastern
Subject: Re: [OpenAFS-devel] Selecting a configuration file format for Open=
AFS  Services

> 3. The one thing I feel more strongly about is this: =C2=A0blocking new c=
onfiguration options because we don't have a config file is not necessary t=
o motivate people to support or to implement a config file. =C2=A0When we h=
ave the config file, it's no force to move less common and more elaborate o=
ptions in to the file. =C2=A0"We need a config file" to reduce complexity, =
isn't a good argument for blocking new features. =C2=A0Yes, early adopters =
of those features might find those features' configuration moved to a confi=
g file in a couple of months. =C2=A0We will all deal.


the issue from where I'm sitting is that anything we start supporting
(command line) we end up supporting ~forever, so if it's unpleasant,
i'd rather not start down the road at all.