Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115782 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 8172 invoked from network); 23 Aug 2021 22:23:22 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 Aug 2021 22:23:22 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 29B661804DB for ; Mon, 23 Aug 2021 15:57:11 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, 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: Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) (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 15:57:10 -0700 (PDT) Received: by mail-pg1-f174.google.com with SMTP id x4so18011317pgh.1 for ; Mon, 23 Aug 2021 15:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ve1dc+lNjDASs1IeNr2cIL8+PEXj61UEHV3TuBWt25g=; b=nz5m0H6c7dePVZWW97f+12XEr9AoSs7Vsjf4YZyf2cjbnZOLDWdPcANWuzNopyNKbm tGhnOIdnUleRHGFw2gxiyoQ+0vGtUqhNo4pUrwHT7R9M/T2YMOgLVv7QnHLyEdaA6R96 sQTC5Mcxa5hpm4i6V2yowM5XKgisvbIZkgymkopX4mRVhcD+qJYdKEELXcT/mVaVUTRf V5IhSQ/zt5GS7u2JXirfJRyn5DIEtmNuiYJaOTSTuTkCKBe1ajRSvT9ra1hU5u1RQ5ua rxn/G0j23YVpxFQekGIIOWAl0y1YYr/YAdMlkfZzzbCnt6P4vHoVUSX4Uk5SYScUdFZi BnZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ve1dc+lNjDASs1IeNr2cIL8+PEXj61UEHV3TuBWt25g=; b=Tg7a+gIn4JgeVYvGR+bt6z0d3Sa+cemnqRs70gx+gnC+Xo53+uFop1wGD8zATl2U0e xqXippB7UaRE7Klf99wbzcgvuNp9eYZaMadmjxl93uwGmQtDdeat5aiis6/T0vK7rXCS 9I3XsoULj7sRoEscgwI/eUqLQrBxiTuZ2BUCKzPYImAba2zumPFzSICnCzRcrS4Y8Veo igk4kMgfKUqOiFdqV4YpjYenSGxhDc8DCigfqYYD2Hb/ox1CRpLsSjuX9i4M+z7VtfTr FA358Bf5DgzTdqQOhVKqz2nLMbF2DP15T12q8bS6fbozsOAqKely+b/ogqHubVZAwMjK C2jw== X-Gm-Message-State: AOAM533LIysxN6hiSuiF4+PZRZkXcnCWmLupSCwrsEiFBXRAg1Sc4w4P oWiio6wV7VpJIrSz+FrN+os= X-Google-Smtp-Source: ABdhPJw//qsEi8w5NmcnA3BCVRqllFciyr4wjNP0Bg75cBDzb1/S2xfCiluo7iu6WfSYOqWXEgHwEA== X-Received: by 2002:a05:6a00:1c5d:b029:3e0:6fb9:1de4 with SMTP id s29-20020a056a001c5db02903e06fb91de4mr36748727pfw.21.1629759429337; Mon, 23 Aug 2021 15:57:09 -0700 (PDT) Received: from smtpclient.apple ([212.102.47.145]) by smtp.gmail.com with ESMTPSA id z4sm246486pjl.53.2021.08.23.15.57.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Aug 2021 15:57:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) In-Reply-To: Date: Mon, 23 Aug 2021 15:57:07 -0700 Cc: PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: References: To: Deleu X-Mailer: Apple Mail (2.3654.100.0.2.22) Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze From: tobias.nyholm@gmail.com (Tobias Nyholm) Thank you.=20 I appriciate you bring up this issue.=20 Situations like this often requires a judgement call rather than = something that could be defined as a policy.=20 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 = managers 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=9Ct= his is rushed=E2=80=9D. I think we can trust the release managers to = make the correct desiccation without an extra policy.=20 // Tobias > On 23 Aug 2021, at 13:48, Deleu wrote: >=20 > Hello everyone! >=20 > 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 = 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]. >=20 > [1] https://wiki.php.net/rfc/namespaced_names_as_token > [2] https://wiki.php.net/rfc/attributes_v2 >=20 > 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. >=20 > In order to not be empty-handed, I started a gist that can be seen as = the > starting point for this discussion, available at > https://gist.github.com/deleugpn/9d0e285f13f0b4fdcfc1d650b20c3105. >=20 > 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. >=20 > Marco Aur=C3=A9lio Deleu