Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110549 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 38101 invoked from network); 16 Jun 2020 00:26:54 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 16 Jun 2020 00:26:54 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id CF7CF1804F6 for ; Mon, 15 Jun 2020 16:12:12 -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-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) (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 ; Mon, 15 Jun 2020 16:12:12 -0700 (PDT) Received: by mail-io1-f49.google.com with SMTP id m81so19909754ioa.1 for ; Mon, 15 Jun 2020 16:12:12 -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=Bck1goulgThmzKL7GqhxMprdOkLr803DgT6Sh+e/nyo=; b=UNlIeNSF8clCbdZgUH1jzt6PAUmL184CN3QkhzPjX99lwh1M9aUDNoNmc3DhhTOLKc gBgnP1as27GlkWA7/sT6E6Jm/jAL04ayA/FQdrirrgB1ndRAs9kup8kpa9uo/gR2fA6L /+d9jzzqvySRp5aYz9T63BNfYtKj+AgR3m91Tp1xc1koHAdjtxzJmkh3yafqu9fjOtM1 hvPVdzftthe2n+0e4C2lQnl+CVHW1Le9RcMIwZRqGD/aGxpkkSHXgCGUlpoJv7XO8nPC 48i6L8cP9f5hzmYysPDFYPkLCz+IghI1yWzJqBrJkx8ysgyG/A6IwTkmX/b1pT8dOOOt 65FA== 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=Bck1goulgThmzKL7GqhxMprdOkLr803DgT6Sh+e/nyo=; b=bxFZLad7tu6tVpgavEMSbpQ7E1bSjHwzM3IoEPnepSaDBdj5SiFTS0JuLKpzY4c8af P8U19713nhVPsQFkyGOXyqz5qbZsFHAXAkAs+toBxWfMiWsmO7ZxKPwkcor1JozBsYXj HZ54PBjLq5NKVgSoV3tUL11KSldwLeN+7xCAwFCvJ9kDcMFFXF68aUWHSs2XPNRSO9RG eEa7eO2I4g5Z8vD24dOB4Xdtm5Y7ZWqhR6XdPdGvv25IKBugXRxYU0d7Hho6WjrOEaIY uT7MR1zcxJP/8KeeQh0zQIks0bwQNxBARXQiwAK3qQ5OaV8hSdxkDrsHdvqGQsc5z88q fmnw== X-Gm-Message-State: AOAM531ziw3p1qw59e6knEXDmvbXdynfbCnnPzyYLTbPGnvvsXwk2TJV RcNTsDN3sE74KaavXkoBlY19KQlnQEJ7F07FLL8= X-Google-Smtp-Source: ABdhPJx6PRIWINS2BVNdsjUmLYeNcBPiuqSaIFOSaWYX7VGEj6lBJNsxbgKHe7QJpJA50Zf1vO5j9V52UuL2pAG2z8w= X-Received: by 2002:a5e:a705:: with SMTP id b5mr280072iod.12.1592262729545; Mon, 15 Jun 2020 16:12:09 -0700 (PDT) MIME-Version: 1.0 References: <4b921c5f-db2b-1e2a-ed2a-1add5c9b6663@gmail.com> <20200615174645.GP14030@phcomp.co.uk> In-Reply-To: Date: Tue, 16 Jun 2020 01:11:59 +0200 Message-ID: To: Kalle Sommer Nielsen Cc: Lynn , PHP internals Content-Type: multipart/alternative; boundary="000000000000623c1805a8278e9f" Subject: Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace. From: deleugyn@gmail.com (Deleu) --000000000000623c1805a8278e9f Content-Type: text/plain; charset="UTF-8" > I am sorry but I do not think you understand the scale of which the > PHP project is at. I'm sorry but you did not get my point. As mentioned above theres 170 places mentioning the term blacklist. When I said "the argument of BC without knowing the scope" I meant to express that perhaps 1, 10 or 100 of these could be changed without any BC impact, meaning that perhaps they barely need an RFC in the first place as it could potentially be just internal code. Instead of being negative and dismissive of a chance at a diverse and welcoming environment, let's see what we can easily do first and take the first step towards making a statement in favor of a better community. On Tue, Jun 16, 2020, 00:50 Kalle Sommer Nielsen wrote: > Hi > > Den tir. 16. jun. 2020 kl. 00.41 skrev Deleu : > > 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 > --000000000000623c1805a8278e9f--