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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:

> The terms "allowlist" and "denylist" are self-defining. One "allows" things
> while the other "denies" things.
>
> These are better terms over "whitelist" and "blacklist" which require prior
> knowledge of the terms or cultural expectations around what each color
> "means".

Half Devil's advocate mode on, as I got up on the wrong side of the
bed this morning.

I am very much for consistent uses of allow/deny and I think it is a
good idea to review and apply this series.

But I'd prefer to see us more honest to ourselves.  Like it or not,
the code comment and documentation are targetted toward those who
can read English, and when you say something is whitelisted in
English, you know exactly what it means, due to shared knowledge of
historical use of the word.

We are doing this change in the name of inclusion.  I find it
intellectually dishonest to avoid saying that true reason, and
instead say the allow/deny pair is more "precise".  They are not
more precise.  In fact, the fact why you have to choose between deny
and block and defend deny over block shows that these words are less
precise.  People who use white/black do not have to choose between
black and other colors and say "white/red may be OK but we choose
black because..." to defend the choice of their words.

The reason we do this change is because the project thinks that it
is the right thing to encourage the adoption of these more inclusive
words, together with other projects that did the same.

In addition, they are words more widely accepted in today's world,
and new folks are more likely to be educated with these words.  As
time goes by, the historical white/black will be less understood, so
it makes it a future-proofing change, as well.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux