Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110594 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 45108 invoked from network); 16 Jun 2020 15:27:30 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Jun 2020 15:27:30 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2B85B180506 for ; Tue, 16 Jun 2020 07:12:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 16 Jun 2020 07:12:56 -0700 (PDT) Received: by mail-vk1-f176.google.com with SMTP id m23so4843526vko.2 for ; Tue, 16 Jun 2020 07:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=03qDJYCqgRU5e6QHox2AIYBINo2d9DrS8W+eYMPi4to=; b=uarwoJNLQi6wvfxGwQabYGBcCjrjE9lYfp4rdBg3mW7G+Ofkc/Kl7Qf1BQpb5EYbeF hNue5YyokzTtGaul9XThXf+7ZQr3V6cW7cNUTVrOwx9KcnuPzT85Oqe5YnRKRvrAGssK il85s15P0/9erDImvxZybgRzKsHPgmBAukMzqnrHDxa5boRvNbZjyuhaIoylAAw9zvWN u6MKKL6sM2dh8o6LjVYHaCBVRd18mC+zEuWquE9RmeSTcoR8wq+ktKc7wrxXOpsbh3E8 /8bidZdKgNz3k9rpL1F4IoauY7aZs0v1Wx6pH+uT5Bz6q11dw2AU2PZmEEIQDY1TDaZV NXmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=03qDJYCqgRU5e6QHox2AIYBINo2d9DrS8W+eYMPi4to=; b=kl2VYQhA8o0TBRcAMX9rIM2rC9JXGlzpRVbcKeRRaEpmWqI/SDEFgdzUPJsvnz3/qk nEF/PGdnJds7i8b8WE2DaqoKByf6VRDZbIV3bsTQaFzujnvsF9o07UD3rsPohyDv7dWG NNqIQip7AJBg8gLyNFfU49pkjAIR3MJhBcbp2ihqigPBzhf/V7QTz9VHS3SWMFOYRdu2 fLqldMSvYAT8bJV0RLIzm7fMBgpxlY6vY/+zuxYooVftNvuDvCYgcXkVJn4GWvldPwnw kQ8LNdSrhH0YmJGLZQltVGUB3pv5YoTKVpxvGfOLLUZnxwPJkgXSOamxpK0311J5DBs4 GgZw== X-Gm-Message-State: AOAM530YuCbr/jmbFCXboU0c+v5QlGMwWXj2d+wml1S12vGJB1vaaNTk sw9+gWCUCj40CVJ4FwH8IRQuk/wb11DlnqhkcqK6Bt46 X-Google-Smtp-Source: ABdhPJyBSx+TdelUluzMXsZtSqVyQxYi2fvWblfirpeKCpiEwpdTG9I5oHXkrgI1qxCexJZd+q7nEMJ72MwLIVmTngk= X-Received: by 2002:a1f:a297:: with SMTP id l145mr1771895vke.10.1592316775177; Tue, 16 Jun 2020 07:12:55 -0700 (PDT) MIME-Version: 1.0 References: <37381398-3330-e5c3-4ae8-e668ca545194@lsces.uk> In-Reply-To: <37381398-3330-e5c3-4ae8-e668ca545194@lsces.uk> Date: Tue, 16 Jun 2020 10:12:43 -0400 Message-ID: To: Lester Caine Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000c120ba05a8342316" Subject: Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList From: chasepeeler@gmail.com (Chase Peeler) --000000000000c120ba05a8342316 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 16, 2020 at 9:55 AM Lester Caine wrote: > On 16/06/2020 13:14, Micha=C5=82 Brzuchalski wrote: > > I'd like to start a discussion period for my RFC which proposes to chan= ge > > the use of "blacklist" in Opcache configuration with better > > self-descriptive terminology. > > Since there will be a higher level change to all these terms - in all > likelihood - trying to push yet another term that does not match the > current discussions elsewhere seems somewhat premature. The NEXT RFC > will be to bring this in line with the 'new' industrial standard, so is > there any point jumping the gun before the international debate has > finished? "blocklist", "banlist", and others all have appropriate > application but like "excludelist", they all imply a narrower usage area > while "blacklist" is accepted generally across all applications. > > What ever alternative to "blacklist" is adopted elsewhere is going to > cause confusion and adding to that confusion with a different > 'translation' just makes the situation worse? > > I agree with this 100%. Without offering an opinion on whether or not we should change it, I do think it makes sense that if we do change it, we at least wait until a more standard term has been decided among other developers and projects. It would also provide another justification for the change, if the change was being made to align with industry standards. I also want to point out my agreement with others that have posted about the current climate not being conducive to an honest conversation on this topic. The current climate in the US is such that often it's not enough to agree on what the end goal should be. If someone doesn't agree with how we reach that goal and why we should reach it, they are treated as if they are against achieving the goal altogether. This topic is very susceptible to those kinds of reactions. > -- > Lester Caine - G8HFL > ----------------------------- > Contact - https://lsces.uk/wiki/Contact > L.S.Caine Electronic Services - https://lsces.uk > Model Engineers Digital Workshop - https://medw.uk > Rainbow Digital Media - https://rainbowdigitalmedia.uk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --=20 Chase Peeler chasepeeler@gmail.com --000000000000c120ba05a8342316--