[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e41ded21-1432-afa8-2e42-e509539281c4@gmail.com>
Date: Tue, 7 Jul 2020 01:58:21 +0200
From: Tibor Raschko <tibrasch@...il.com>
To: Dan Williams <dan.j.williams@...el.com>,
torvalds@...ux-foundation.org,
ksummit-discuss@...ts.linuxfoundation.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org,
tech-board-discuss@...ts.linuxfoundation.org,
Chris Mason <clm@...clm>, skhan@...uxfoundation.org
Subject: Re: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology
> The suggestions you made will help us adapt inclusive terminology
> for the current times, and also help us move toward terms that are
> intuitive and easier to understand keeping our global developer
> community in mind.
> Allowlist/denylist terms are intuitive and action based which have a
> globally uniform meaning.
Nobody has a problem understanding "blacklist" and "whitelist". These
are universally understood words even outside of computing. Claiming
that we need clearer alternatives is smoke and mirrors.
> Terms such as "whitelist" etc are contextual, hence assume contextual
> knowledge on the part of the reader.
We are talking about the source code of and interacting with an
operating system kernel. Naturally, most things here are contextual and
require domain knowledge to be understood correctly. Not requiring
contextual knowledge when reading the kernel sources doesn't sound like
a realistic argument.
Raschko T.
Powered by blists - more mailing lists