>>>>> "DW" == Dave Wolfe <email@example.com> writes:
DW> I'm all for configurability, but this sounds like yet another way to
DW> break approve. I think the only way a list-configurable approve header
DW> will work is to make it Yet Another Field on the .majordomo file
DW> line. Do we *really* need to configure that?
If the default doesn't change then there's no reason to add a field
(i.e. make the field optional). I'm pretty sure that the approve utility
is going to have to change anyway. The problem is that it seems that a few
sites have real problems with what we have chosen as the Approved: header,
and configurability is the only real way around it (except saying "tough").
That or force a change to, say, X-Mj-Approve:, which I think is much more
disruptive. I do not believe that the level of hacks proposed in this
discussion to ignore and pass Approved: if it isn't needed are materially
better (and IMHO they're much worse).
Plus configurability gets around the "hardcoded string" problem; who likes
embedding these things straight in the code, possibly in several different
DW> I really think it's just one more configuration option in what's
DW> rapidly becoming an expanding maze of configuration options that 99.97%
DW> of the users don't care about and don't matter anyway. (Pay no
DW> attention to the grumpy old man behind the curtain.)
Then hide them in configuration groups that aren't shown by default. We'll
have to do this anyway for options that are pretty rarely set and which are
confusing to the novice. I guess I should spend some time and write up a
description of the implementation of groups and security levels that I have