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, even 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" <[email protected]> To: "Matt W. Benjamin" <[email protected]> Cc: "OpenAFS Devel" <[email protected]>, "openafs" <[email protected]> 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 OpenAFS Services > 3. The one thing I feel more strongly about is this: blocking new > configuration options because we don't have a config file is not necessary to > motivate people to support or to implement a config file. When we have the > config file, it's no force to move less common and more elaborate options in > to the file. "We need a config file" to reduce complexity, isn't a good > argument for blocking new features. Yes, early adopters of those features > might find those features' configuration moved to a config file in a couple > of months. We 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. _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
