Andrew Deason <[email protected]> writes: > Russ Allbery <[email protected]> wrote:
>> OpenAFS has way too many options. OpenAFS should have fewer options >> that actually work and are tested, instead of lots of options no one >> tests and that therefore bitrot. > I disagree that OpenAFS has too many options; it has too many options > that are useless (or poorly understood/documented). OpenAFS could use > more options in various areas that are currently hard-coded, and could > definitely use less in others. I completely disagree with the idea that OpenAFS should have more options. Completely, and very strongly. There are many places where the behavior is wrong, or suboptimal, or needs improvement. But not by adding an option except in rare cases, at least not permanently. By *fixing the code*. > Most of the time it's where we drew a line in the ground for a > speed/memory tradeoff, Then we should pick better tradeoffs or dynamically tune. Not add more options. Look at the mess with cache tuning, and the mess with file server tuning. The existence of the options rarely helped anyone; what really helped people was to change the code to dynamically tune. > I can agree with this, but I do not see a reason to prohibit the > administrator from making such decisions. OpenAFS is open source. The administrator can always make the decision. Adding an option means that we, as a project, are supporting the option. Every setting of the option. We don't have enough manpower to support the behavior we already have. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
