Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110548
Return-Path: <kalle.php@gmail.com>
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 31182 invoked from network); 16 Jun 2020 00:05:00 -0000
Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5)
  by pb1.pair.com with SMTP; 16 Jun 2020 00:05:00 -0000
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id B4D711804DC
	for <internals@lists.php.net>; Mon, 15 Jun 2020 15:50:18 -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=1.3 required=5.0 tests=BAYES_50,
	FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,
	RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: <kalle.php@gmail.com>
Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194])
	(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 <internals@lists.php.net>; Mon, 15 Jun 2020 15:50:18 -0700 (PDT)
Received: by mail-pl1-f194.google.com with SMTP id j4so4209355plk.3
        for <internals@lists.php.net>; Mon, 15 Jun 2020 15:50:18 -0700 (PDT)
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=SMG7yG5RlvfV7XFKEvoDnbCYVpA1i3wh+u6wCyc1T0o=;
        b=QbFHbSUdfYfLIvauqi3uE+xEgIMfqXE9JmAETkSUMT0+sKOCGSCze+viZLVCKA+Y/z
         hp0tAwL32NJWO4+u6DYKp8xmRmXq2aVeOMx2E7WHZskgEj4Jz1nVBe74ZaOHLfStrVNR
         G0J7SGasrnMk8OhmDpgcVGRoxVcfj8+UhpDJOyI3ZIVI2RRJDK8qX2+wRSuWj++hbNsu
         VCXgZrd6W5AGKVQHr4YKCUyGvD3+2xOmLSpifcYn1jAxcZzQcmsXi1BsbJHFUUdvaKXR
         wO4qAwjeJ6TcFVEPO+4gbdUYU5m7oxxl3aY918vR58YovGe9Wvm60CugxWxPc47M3Dmv
         GfCA==
X-Gm-Message-State: AOAM533otKM+9VACcUSzJqxAVMIuSWEwDB30fTMUpj4H5w2+v2OXoUuA
	hEjtJUwdEIl1JzsT1sCE3tC4TR4EAHV0mHmUY/s=
X-Google-Smtp-Source: ABdhPJyHZRXX0Vw6k49zoShLOamv1CkalxRWyETgn3NTeahwGURVtQVUAsF4WiO3m6EMGk19CwUUNN1CyhHVgyLZnyc=
X-Received: by 2002:a17:90a:240c:: with SMTP id h12mr190832pje.42.1592261417285;
 Mon, 15 Jun 2020 15:50:17 -0700 (PDT)
MIME-Version: 1.0
References: <BY5PR15MB3729227C6536FA3D0EBE2335929C0@BY5PR15MB3729.namprd15.prod.outlook.com>
 <4b921c5f-db2b-1e2a-ed2a-1add5c9b6663@gmail.com> <20200615174645.GP14030@phcomp.co.uk>
 <CANS-=peH1x-1LAr6pxp4bvToVB8hQ7GT_2xynsDmp1W7bDR7ag@mail.gmail.com> <CADK1yXJEV_Kuxhr6LqLd+9sXkaboXH5cLW3NnJBaa7=Op72ZXg@mail.gmail.com>
In-Reply-To: <CADK1yXJEV_Kuxhr6LqLd+9sXkaboXH5cLW3NnJBaa7=Op72ZXg@mail.gmail.com>
Date: Tue, 16 Jun 2020 01:50:04 +0300
Message-ID: <CAJW__o12mwJ68=yKQzNTAGf+ViFV-=TMhhtRPw9weP1wJ+at5g@mail.gmail.com>
To: Deleu <deleugyn@gmail.com>
Cc: Lynn <kjarli@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] About the use of the terms master/slave and blacklist,
 proposal to replace.
From: kalle@php.net (Kalle Sommer Nielsen)

Hi

Den tir. 16. jun. 2020 kl. 00.41 skrev Deleu <deleugyn@gmail.com>:
> People arguing BC breaks without even knowing the scope of the change
> clearly show biased.

I am sorry but I do not think you understand the scale of which the
PHP project is at. Any change we make to the language has consequences
for hundreds of millions of websites running PHP, potentially millions
of developers who work with PHP and so on. Therefore any change that
breaks backwards compatibility in any way has to be justified. We have
a rather strict BC policy, something that allowed you and millions of
others to easily upgrade from PHP5 to PHP7 with next to no changes for
the most part. Do I personally believe that a change of name for some
directives, potentially more, are justified? No I do not. That is my
personal bias here.

Let's assume that 10% of the current user base of PHP upgrades to
whatever version a change like this is implemented. The number of work
hours spent on investigating, updating, testing and patching these BC
breaks which are changes for the sake of change is a crazy amount of
hours invested into it. Opcache is a very popular extension, changing
an ini directive means change of build systems, you can certainly
argue that these changes could potentially just be changed by a tool,
but even doing so will have cost a substantial amount of hours to
implement and test. It is easily in the thousands of hours, a normal
work year for me is about 1900 hours in terms of hours for just one
person. Demanding that our users should invest so many hours besides
the usual amount for already upgrading to a PHP version is lunacy,
especially if the change is to try censor something that has no
correlation to any racial slurs.

So to say that the arguments about BC breaks (which I believe I was
the only one to post about in this thread) without knowing the scope
of the change is void. Yes, any policy for backwards compatibility
breaks can easily be classified as biased, because they are an opinion
of the project as a whole, or rather, a policy.


> As white men, we're being dismissive, insensitive and strongly suggesting
> we don't want change. While people may not feel offended by any of these
> terms being discussed, this thread alone already serves as reason for
> people to feel like there's no room for diversity in the internal community
> of php.

The "we" in this is extremely biased, it attempts to force me to feel
as an inferior human (to steal the term from Larry above), because I
do not agree with your request for a change. The classification you
just did there is something I personally would feel offended by,
because you attempt to use my ethnicity as an argument for why I feel
the way I feel.


> I believe that if we cannot come together to take the small (potentially
> insignificant) step towards making changes that signal a welcoming
> environment, how are we going to actually take the big steps?

We could start by taking steps that matters for once, censoring words
that have no correlation to any racial issue because it might offend
someone because it has the word black in it. What about whitespace? Am
I a nothing, an empty space just because I am caucassian? There are
other issues we should tackle to make PHP better, after all, we have a
major version in the works, set to release later this year. Something
(excuse my bias here) is way more important than trying to justify
backwards compatibility breaks for no reason.

-- 
regards,

Kalle Sommer Nielsen
kalle@php.net