Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115783 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 24607 invoked from network); 24 Aug 2021 02:10:11 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 24 Aug 2021 02:10:11 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8375018053D for ; Mon, 23 Aug 2021 19:44:00 -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.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, 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-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) (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, 23 Aug 2021 19:44:00 -0700 (PDT) Received: by mail-ed1-f46.google.com with SMTP id cq23so29227125edb.12 for ; Mon, 23 Aug 2021 19:44:00 -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=3dfSJGTLb0031v2jAPDB3tjxVNG03DTZB6yrnMN59r4=; b=Je0S29NcD/RDAD3XbZlqM6SeJG/LF7YvkfNRYmJyhB2nxpVKP2cxpMytuvDdIwDip9 bsDqSsXcqo85A6NBnzIt+dSxZ0UuG7RB3zdJnfP0Qn5nDCRhCQ91J0iRBYnAuur4Y6/+ 4s4FPjWw/pJ7liR9CzHn8Z/djJmWazdAHLuw2t7Cx8sU4FJr6O7GWtMCRSNR/J0OP6CX TCwz3nbHFdk40aLaDh01ZEqZzQNIoHFr2SS7V/ZP2bB2CeWDZ0EyjoJlGM2lCbOlSrua nxgzRqxihL4PBhRwJs4uozHvblJ6p6zMDblP7gM+usRItRQdxMtz46aUi3ZSJqDu6hEf /+5g== 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=3dfSJGTLb0031v2jAPDB3tjxVNG03DTZB6yrnMN59r4=; b=ZqKewj3Gm+OBQLE3fTfAViqHJL7di58SW2NX9sGM0l8nYorQBHwKZj5Ry3Qm8ptKiw VNjDIci8dmsWt9EkrchI9VAENrZR+3H4D0hiXhu8UOyajSDeNKjPJXo9L/zOsOe4KUgs z0TCe0DMws52leXImee+k7dgQGErwxMKn7F1TXN8SbEFy3LaPRR30bnsYGCAeKTy372q Du+AiJ+qrhOecVRnZdoz5Vwf3eDtFNnUteVUjIkkW/dQE7Ti3K49rGzbf0gSHFaci4Zz cSfec6gSxgze0bKYONf5JBvm+VX/9xDHE8O4ub8Ru8k9seoa7EX6KOuawBZXK+n2AmC5 MUJw== X-Gm-Message-State: AOAM533DabiNB4iXgiOehnMGM67zL/inR1am/maZ4GlEDgFGAyTU2w5e OBxzbzvUyRb33qNlKKmoBWKnWY91jCJKNQUU8k4= X-Google-Smtp-Source: ABdhPJx4aRukechRW2UTqaH3FIrCCmsczpQaCJcymGvDT/wpItgKChC5qHoCqa+ciC/vQStvd5V8QgI8znceqh/sR0c= X-Received: by 2002:aa7:c810:: with SMTP id a16mr39998746edt.195.1629773037286; Mon, 23 Aug 2021 19:43:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 24 Aug 2021 08:13:45 +0530 Message-ID: To: Tobias Nyholm Cc: Deleu , PHP internals Content-Type: multipart/alternative; boundary="000000000000f3b82405ca451a36" Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze From: faizanakram99@gmail.com (Faizan Akram Dar) --000000000000f3b82405ca451a36 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 24 Aug 2021, 4:27 am Tobias Nyholm, wrote= : > Thank you. > I appriciate you bring up this issue. > > Situations like this often requires a judgement call rather than somethin= g > that could be defined as a policy. > I suggest the release managers always should be in agreement before a RFC > is created during a =E2=80=9Cfeature freeze=E2=80=9D. If the release mana= gers agree that a > change can be added, then the discussion and the vote should not consider > =E2=80=9Cif it is too late=E2=80=9D or =E2=80=9Cthis is rushed=E2=80=9D. = I think we can trust the release > managers to make the correct desiccation without an extra policy. > > // Tobias > > > On 23 Aug 2021, at 13:48, Deleu wrote: > > > > Hello everyone! > > > > We recently had the Nullable Intersection Types RFC process in an > > unconventional way starting a new RFC post feature freeze. If memory > serves > > me right, another similar incident happened with the Attributes RFC whi= ch > > 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]. > > > > [1] https://wiki.php.net/rfc/namespaced_names_as_token > > [2] https://wiki.php.net/rfc/attributes_v2 > > > > I would like to gather opinion on a potential Policy RFC that would > define > > some guidelines for such a process. As Nikita pointed out [3], the > ability > > to refine new features is both important for the developer and > undocumented > > for the PHP Project. > > > > In order to not be empty-handed, I started a gist that can be seen as t= he > > starting point for this discussion, available at > > https://gist.github.com/deleugpn/9d0e285f13f0b4fdcfc1d650b20c3105. > > > > Generally speaking, I'm first looking for feedback on whether this is > > something that deserves attention and an RFC or is it so rare that it's > > fine to leave it unchanged. If there is interest in moving forward, I > would > > then also be interested in suggestions on things that should be > > included/excluded in the RFC. > > > > Marco Aur=C3=A9lio Deleu > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php Hi, I agree with Tobias. Such changes / requests are rare and require a judgement call. PS: Sorry if my email was posted twice, I replied via a different email which is not subscribed to internals list, so wasn't sure. --000000000000f3b82405ca451a36--