Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125688 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id A591A1A00BD for ; Thu, 26 Sep 2024 12:50:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1727355142; bh=EkpEZYxRa5hlhzivQBThPIlnCwsGqahIBxJFkJYw+oo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=dz2I68E/bZyctlnl91nQuv6gqLlGgAdWLlrtpAHnzBpkSaADzksbVKfV3MbSogIyz Ws6C8ZHUL8uiaCQ5j7aRtqlqp2I0S+BEaAu0R6PH7oA1+3A+/tkFDSXVLGHGIc9H0a tGefmdPSuEhE8e1blIlmEfFK2SDa6odeNnjd5P9J80jzMolrKswllSkFbcAqEBN2I2 +UyI1ikYjTunXaBinSUNXm1E/Z4RG+r5rP6MGWk/6EyMRd0gsCmyFlxojJg/oCfW9l pPDqWU9AmL/Kdt2TObs+1Fn5q6WA5AsikNYnDLk59KFhVZQjL3vGGv7aYWDIi7UVvT O6vU3VWqDeHbQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C848518006F for ; Thu, 26 Sep 2024 12:52:21 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: * X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_50,DMARC_NONE, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-oa1-f42.google.com (mail-oa1-f42.google.com [209.85.160.42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 26 Sep 2024 12:52:21 +0000 (UTC) Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-2870058ffaaso219425fac.1 for ; Thu, 26 Sep 2024 05:50:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727355010; x=1727959810; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1SXMjr064mgbpnmxml6Hxni4cM6yGSNkNk5hFtzbT0I=; b=ZtcpVvU2B1BvXiKWgDGcdtw/+t0y0moRJ8FKuxulbStRiENglrHlc2PtMr5LXbOpr2 S9GTqyemiCMS00ck91fUr25gKgmf9xSFrlEeUbcBGAx1uGdT0hSTqd5v6Z7b6BHNTcTS LhRogmvauU83vvgFgsAfpVcK80P6Y9bPWbXFCuK+RWEazMxO7T3zEgH3KGJg5hEi3h00 +jToXLz7XpS8fujPDju6yGT9foPuzw+8H+Oi+n1JMnwky+uiqtbQiZd60G9rDiMficXa 3kxxwmrhVv4AWRYZSstY1bdKrvDOLTrpFL3L8RMaPFKV2FWs6Vv1sINicc9Lb4SMe3B8 R0FQ== X-Forwarded-Encrypted: i=1; AJvYcCUGyJWIbh0zqQAZ35VEhoscdVmCdYF4vifili7PkBFuAtoDcr+wO88s/3f7/c2G41gzd0Z0OyqAqII=@lists.php.net X-Gm-Message-State: AOJu0YxXUi3QtEu2DEi0pyttvgSeghA9kmLOvnw51/cXeUoFHAlLfSe1 eRe+Nc7zGRVDmxZmBvUS7e3jqPYwBdLsB8vvT1zCNxH0VqMuAGB1SM9dX48Rk5Psn58c6SACsAe JDo2rQqne1qsNETqfaSA6R758/LI= X-Google-Smtp-Source: AGHT+IFPdw5UdgzM2TxxjZ/3LccWKESXS5WEl2R34DrNlBZ9k5NacRZgTS+JYDl7VbHFJwd8rJToRLxbhdS41RvxN1U= X-Received: by 2002:a05:6870:c190:b0:277:d2ee:175c with SMTP id 586e51a60fabf-286e14228femr4642198fac.20.1727355010475; Thu, 26 Sep 2024 05:50:10 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: <16d24095-564a-41f1-bf7f-cee9466f76ea@gmx.de> In-Reply-To: Date: Thu, 26 Sep 2024 13:49:59 +0100 Message-ID: Subject: Re: [PHP-DEV] No more RFC implementations during beta phase To: Bob Weinand Cc: "Christoph M. Becker" , internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000ccee080623052d44" From: bukka@php.net (Jakub Zelenka) --000000000000ccee080623052d44 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Tue, Sep 24, 2024 at 4:53=E2=80=AFPM Bob Weinand w= rote: > On 24.9.2024 17:14:20, Christoph M. Becker wrote: > > Hi all, > > I want to suggest that we do not allow any RFC implementations to land > during beta phase. In my opinion, the remaining time to thoroughly > check and address possibly overlooked issues is way too short otherwise. > > For instance, the implementation of "Deprecate proprietary CSV escaping > mechanism"[1] landed just prior to 8.4.0beta1[2]. However, a serious > issue with that implementation had only be fixed about two weeks ago[3], > and the discussion what to do about that[4] is still unresolved. > > So in this case, the implementation would have been right in time, but > still somewhat late. > > An even more problematic example would be the "Support object type in > BCMath" RFC[5]. This has only been implemented shortly prior to > 8.4.0beta5[6], so there has been almost no time to address overlooked > issues prior to 8.4.0RC1. A pretty serious bug in the implementation[7] > has just been fixed[8] without any real chance to discuss the actual > fix. I'm not arguing that the fix should be reverted, but I'm rather > pointing out that late RFC implementations could easily lead to those > issues over and over again. > > Thoughts? > > [1] > [2] > [3] > [4] <= https://github.com/php/php-src/pull/15569#issuecomment-2354447087>ff > [5] > [6] > [7] > [8] > > Christoph > > Hey Christoph, > > I certainly can see where you are coming from. But that's mostly what is > defining the beta phase - an evolving version of PHP, but where it's clea= r > which features will make it (i.e. all RFCs have to be accepted by then) -= a > period where people can start introducing support for the next PHP versio= n > without being surprised at yet unknown breaks. > I would actually like to see it more like the beta should be a version where all big features are implemented and just minor features and potentially ABI breaking fixes or some not too big refactoring is added. RC should be really a stable version that can be tested and only bugs are fixed in it. > I consider it important to retain the policy of submitting RFC > implementations during beta, so that implementations are not rushed and > thoroughly reviewed before being merged. The cutoff for RFCs being accept= ed > is the first beta, but a lot of RFC implementations don't quite yet have > the desired quality for merging. It's important to allow implementations = to > mature before merging. > I would maybe suggest that we actually do cut off for RFC with the first alpha which would give alpha stage to implement it all and beta could used for potentially breaking fixes. During beta I would keep the rule that any features should be approved by RM but maybe add to it that it should be RM or CodeOwner / Maintainer (like one approval from any of those required) so there is some technical input as well in weighting those changes and it doesn't get blocked if RM's are busy. It's really just to catch some big refactoring or some risky changes. Regards Jakub --000000000000ccee080623052d44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On Tue, Sep 24, 2024 at 4:53=E2=80=AFPM Bob Weinan= d <bobwei9@hotmail.com> wr= ote:
=20
On 24.9.2024 17:14:20, Christoph M. Becker wrote:
Hi all,

I want to suggest that we do not allow any RFC implementations to land
during beta phase.  In my opinion, the remaining time to thoroughly
check and address possibly overlooked issues is way too short otherwise.

For instance, the implementation of "Deprecate proprietary CSV escapin=
g
mechanism"[1] landed just prior to 8.4.0beta1[2].  However, a serious
issue with that implementation had only be fixed about two weeks ago[3],
and the discussion what to do about that[4] is still unresolved.

So in this case, the implementation would have been right in time, but
still somewhat late.

An even more problematic example would be the "Support object type in
BCMath" RFC[5].  This has only been implemented shortly prior to
8.4.0beta5[6], so there has been almost no time to address overlooked
issues prior to 8.4.0RC1.  A pretty serious bug in the implementation[7]
has just been fixed[8] without any real chance to discuss the actual
fix.  I'm not arguing that the fix should be reverted, but I'm rath=
er
pointing out that late RFC implementations could easily lead to those
issues over and over again.

Thoughts?

[1]
<https://wiki.php.net/rfc/=
deprecations_php_8_4#deprecate_proprietary_csv_escaping_mechanism>
[2]
<https://github.com/php/php-src/commit=
/c818d944cf998b3151e4b312d655c51223612c4e>
[3]
<https://github.com/php/php-src/commit=
/f756b96e06db29a978bbf3ad3a5c52f6d0d97c64>
[4] <https://github.com/php/php-src/pull/15569#issu=
ecomment-2354447087>ff
[5] <https://wiki.php.net/rfc/support_object_type_in_bcmath>=
;
[6]
<https://github.com/php/php-src/commit=
/fad899e5662d0a929d8462dd8239b0489dd9b53f>
[7] <https://github.com/php/php-src/issues/15968>
[8] <https://github.com/php/php-src/pull/16021>

Christoph

Hey Christoph,

I certainly can see where you a= re coming from. But that's mostly what is defining the beta phase - an = evolving version of PHP, but where it's clear which features will make = it (i.e. all RFCs have to be accepted by then) - a period where people can = start introducing support for the next PHP version without being surprised = at yet unknown breaks.


I w= ould actually like to see it more like the beta should be a version where a= ll big features are implemented and just minor features and potentially ABI= breaking fixes or some not too big refactoring is added. RC should be real= ly a stable version that can be tested and only bugs are fixed in it.
=
=C2=A0

I consider it important to reta= in the policy of submitting RFC implementations during beta, so that implem= entations are not rushed and thoroughly reviewed before being merged. The c= utoff for RFCs being accepted is the first beta, but a lot of RFC implement= ations don't quite yet have the desired quality for merging. It's i= mportant to allow implementations to mature before merging.


I=C2=A0 would maybe suggest that we actua= lly do cut off for RFC with the first alpha which would give alpha stage to= implement it all and beta could used for potentially breaking fixes.
=

During beta I would keep the rule that any features sho= uld be approved by RM but maybe add to it that it should be RM or=C2=A0Code= Owner / Maintainer (like one approval from any of those required) so there = is some technical input as well in weighting those changes and it doesn'= ;t get blocked if RM's are busy. It's really just to catch some big= refactoring or some risky changes.

Regards

Jakub
--000000000000ccee080623052d44--