linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: Jiri Slaby <jslaby@suse.cz>, SeongJae Park <sjpark@amazon.com>,
	Joe Perches <joe@perches.com>
Cc: akpm@linux-foundation.org, apw@canonical.com,
	SeongJae Park <sjpark@amazon.de>,
	colin.king@canonical.com, sj38.park@gmail.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 0/2] Recommend denylist/allowlist instead of blacklist/whitelist
Date: Sat, 13 Jun 2020 00:40:59 +1000	[thread overview]
Message-ID: <877dwcfitg.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <38ac91ab-ced3-8a4f-b825-4503fdcddeb8@suse.cz>

Jiri Slaby <jslaby@suse.cz> writes:
> On 11. 06. 20, 9:38, SeongJae Park wrote:
>> On Wed, 10 Jun 2020 23:35:24 -0700 Joe Perches <joe@perches.com> wrote:
>>> On Thu, 2020-06-11 at 08:25 +0200, SeongJae Park wrote:
>>>> From: SeongJae Park <sjpark@amazon.de>
>>>>
>>>> This patchset 1) adds support of deprecated terms in the 'checkpatch.pl'
>>>> and 2) set the 'blacklist' and 'whitelist' as deprecated with
>>>> replacement suggestion of 'denylist' and 'allowlist', because the
>>>> suggestions are incontrovertible, doesn't make people hurt, and more
>>>> self-explanatory.
>>>
>>> While the checkpatch implementation is better,
>>> I'm still very "meh" about the whole concept.
>> 
>> I can understand your concerns about politic things in the second patch.
>> However, the concept of the 'deprecated terms' in the first patch is not
>> political but applicable to the general cases.  We already had the commits[1]
>> for a similar case.  So, could you ack for at least the first patch?
>> 
>> [1] https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Hugs
>
> Fuck you! replaced by hug you! is a completely different story. The
> former is indeed offending to majority (despite it's quite common to
> tell someone "fuck you" in my subregion; OTOH hugging, no way -- I'm a
> straight non-communist). If it turns out that any word (e.g. blacklist)
> offends _majority_ (or at least a significant part of it) of some
> minority or culture, then sure, we should send it to /dev/null.
> should by no means listen to extreme individuals.

I agree you have to draw the line somewhere, there will always be
someone somewhere that's offended by something. But this seems like a
pretty easy case.

It's not like blacklist / whitelist are even good to begin with, it's
not obvious which is which, you have to learn that black is bad and
white is good.

Blocklist (or denylist?) and allowlist are actually more descriptive and
less likely to cause confusion.

cheers

  parent reply	other threads:[~2020-06-12 14:40 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-11  6:25 [PATCH v4 0/2] Recommend denylist/allowlist instead of blacklist/whitelist SeongJae Park
2020-06-11  6:25 ` [PATCH v4 1/2] checkpatch: support deprecated terms checking SeongJae Park
2020-07-25 13:02   ` Michał Mirosław
2020-07-25 16:36     ` Joe Perches
2020-07-25 17:29     ` Joe Perches
2020-07-25 23:35       ` SeongJae Park
2020-07-26  4:27         ` Joe Perches
2020-07-26  7:18           ` SeongJae Park
2020-07-26  7:29             ` Joe Perches
2020-07-26  7:45               ` SeongJae Park
2020-07-26 14:50                 ` Joe Perches
2020-07-26 15:36                   ` SeongJae Park
2020-07-26 16:42                     ` Joe Perches
2020-07-26 18:07                       ` SeongJae Park
2020-07-26 20:33                         ` Michał Mirosław
2020-07-27  6:54                           ` SeongJae Park
2020-07-27 20:44                             ` Andrew Morton
2020-07-27 20:49                               ` Joe Perches
2020-07-28  6:22                                 ` SeongJae Park
2020-06-11  6:25 ` [PATCH v4 2/2] scripts/deprecated_terms: Recommend denylist/allowlist instead of blacklist/whitelist SeongJae Park
2020-06-11  6:35 ` [PATCH v4 0/2] " Joe Perches
2020-06-11  7:38   ` SeongJae Park
2020-06-11  8:16     ` Jiri Slaby
2020-06-11  8:30       ` SeongJae Park
2020-06-11  8:32         ` Jiri Slaby
2020-06-11 10:43           ` Joe Perches
2020-06-12  6:40             ` SeongJae Park
2020-06-12  7:05               ` Joe Perches
2020-06-12 14:40       ` Michael Ellerman [this message]
2020-06-14 21:29         ` Pavel Machek
2020-06-15  4:21           ` Jiri Slaby
2020-06-15  6:12             ` Pavel Machek
2020-06-15  6:46               ` SeongJae Park
2020-06-15  7:00                 ` Joe Perches
2020-06-15  7:39                   ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877dwcfitg.fsf@mpe.ellerman.id.au \
    --to=mpe@ellerman.id.au \
    --cc=akpm@linux-foundation.org \
    --cc=apw@canonical.com \
    --cc=colin.king@canonical.com \
    --cc=joe@perches.com \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sj38.park@gmail.com \
    --cc=sjpark@amazon.com \
    --cc=sjpark@amazon.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).