Re: [PATCH 0/3] Use "allowlist" and "denylist" tree-wide

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Jul 13 2022, Derrick Stolee via GitGitGadget wrote:

> The terms "allowlist" and "denylist" are self-defining. One "allows" things
> while the other "denies" things.

I've got a preference for things that can be found in widely available
dictionaries, these words seem to be tech neologisms.

The resulting wording also seems a bit ackward to me, e.g. we now say
that some tests are "allowlisted [...] as passing with no memory
leaks". Are we denying or allowing them to pass? No, they're going to
either pass or not.

So to me "whitelist" or "blacklist" is more natural when used in the
descriptive sense, whereas "allow" and "deny" are verbs, so that seems
to impart a sense of actively allowing or denying something.

> These are better terms over "whitelist" and "blacklist" which require prior
> knowledge of the terms or cultural expectations around what each color
> "means".

Apparently whitelist is defined in terms of blacklist, which per
Wikipedia originates in some 17th century play:
https://en.wikipedia.org/wiki/Blacklisting#Origins_of_the_term

> [...]
> Some recommend using "blocklist", but I personally prefer "denylist". To me,
> "blocking" something seems permanent. "Denying" something seems ephemeral
> and related to a specific request being denied due to some (possibly
> mutable) state. I'm open to suggestions here. There are many fewer
> replacements needed in this case.

I suspect the actual motivation is closer to that summarized in :
https://en.wikipedia.org/wiki/Whitelist#Controversy

Personally I'd really prefer if we didn't take these sort of changes,
and took the view that if something was readily understood that it was
good enough.

The CodingGuidelines note that we use a mix of US & UK english, so
forbidding certain words & basically requiring some of us to keep
abreast of the latest political trends in America is a bit too much. I'd
just like to write code, please...

> I did not make any change to our CodingGuidelines. Hopefully having clear
> usage throughout the codebase will be enough to promote using consistent
> terminology.

...particularly since I think what's being implied here is that we can
expect interested parties to be setting up the relevant E-Mail filters,
and asking patch submitters to change wording in the same way as this
series does.

We also have 30-40 uses of both terms in-tree, so it seems implausible
that people are mainly copying existing wording.

A few of the hunks here are changing docs I added, and I just added
those "naturally", i.e. I happened to think of those words to describe
what I was trying to get across).