> 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 OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
