Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115827 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 13438 invoked from network); 25 Aug 2021 17:42:41 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 25 Aug 2021 17:42:41 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2B8031804AC for ; Wed, 25 Aug 2021 11:16:58 -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.1 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_NEUTRAL autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS30827 82.113.144.0/21 X-Spam-Virus: No X-Envelope-From: Received: from xdebug.org (xdebug.org [82.113.146.227]) by php-smtp4.php.net (Postfix) with ESMTP for ; Wed, 25 Aug 2021 11:16:58 -0700 (PDT) Received: from [127.0.0.1] (host81-158-149-195.range81-158.btcentralplus.com [81.158.149.195]) by xdebug.org (Postfix) with ESMTPSA id 359BA10C038; Wed, 25 Aug 2021 19:16:57 +0100 (BST) Date: Wed, 25 Aug 2021 19:16:55 +0100 To: internals@lists.php.net, Nicolas Grekas CC: Deleu , PHP internals User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: <39339286-D521-4DF0-9995-CAB0909E953B@php.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze From: derick@php.net (Derick Rethans) On 25 August 2021 17:58:55 BST, Nicolas Grekas wrote: >Le mar=2E 24 ao=C3=BBt 2021 =C3=A0 21:09, Derick Rethans a =C3=A9crit : > >> On 24 August 2021 19:53:57 BST, Deleu wrote: >> >On Tue, Aug 24, 2021, 19:28 Derick Rethans wrote: >> > >> >> On Mon, 23 Aug 2021, Deleu wrote: >> >> >> >> > We recently had the Nullable Intersection Types RFC process in an >> >> > unconventional way starting a new RFC post feature freeze=2E If me= mory >> >> > serves me right, another similar incident happened with the Attrib= utes >> >> > RFC which had a syntax that could not be implemented without a >> >> > secondary RFC [1] and went through a secondary RFC which proposed = a >> >> > different syntax [2]=2E >> >> >> >> I find this comparison disingenuous=2E >> >> >> > >> >I want to state that I had no intention to compare the RFCs or even br= ing >> >their merits into discussion=2E What I intended to show is that we hav= e 8=2E0 >> >which had an RFC that would classify as Refinement RFC and 8=2E1 again >> having >> >another RFC that also classifies under the same category=2E >> >> That's where I disagree already=2E The nullable intersections RFC isn't= a >> refinement, it's a new feature=2E > >Can you please clarify what you want to express here? Your insistence in >repeating that statement makes me read this as: "the nullable intersectio= ns >RFC was not legal"=2E You're wanting to add a new feature during feature freeze, so yes, I would= n't have allowed it=2E=20 > If that's the case, I find that deeply disturbing, >because I need to be allowed to discuss not-yet-released features during >the freeze period=2E Yes, suggesting tweaks to existing features is fine, up to a certain point= =2E Introducing new ones is not=2E=20 > Whether an RFC should be considered as a new feature >should be the end of the discussion, not the abruptly-closing start=2E Th= e >reason is that there is no precise definition of what "a feature" means= =2E The RFC was "pure intersection types", with a scope decided by its author= =2E That RFC says no Union types=2E=20 >Maybe it's obvious for you in this case, but others shouldn't be denied t= he >right to discuss the topic=2E Discuss whatever you want, but that doesn't mean that a new feature RFC sh= ould be allowed during a feature freeze=2E=20 >I think that we can reach a common agreement by working on the definition >of what we mean by "Refinement RFC"=2E > >Marco's gist defines them as "An RFC proposing changes, amendments, >adjustments to the language while refining an unreleased change that has >been approved=2E" I'm sure we can improve it, but I mostly agree with thi= s >statement=2E My RFC falls under this definition,=20 I disagree that it does=2E Union intersection types is something that the = pure intersection types RFC ruled out=2E=20 > and that should be enough to >end the debate around whether any particular post-feat-freeze RFCs are >legal=2E I think we should focus our efforts on improving this definition= , >and move forward=2E This is all moot, because that RFC hasn't been passed=2E I also don't thin= k it's necessary=2E If you want to disregard the concept of a feature freez= e, that's fine too=2E But not in the PHP project=2E Cheers=20 Derick=20