No more RFC implementations during beta phase

Hi,

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]https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_proprietary_csv_escaping_mechanism https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_proprietary_csv_escaping_mechanism
[2]https://github.com/php/php-src/commit/c818d944cf998b3151e4b312d655c51223612c4e https://github.com/php/php-src/commit/c818d944cf998b3151e4b312d655c51223612c4e
[3]https://github.com/php/php-src/commit/f756b96e06db29a978bbf3ad3a5c52f6d0d97c64 https://github.com/php/php-src/commit/f756b96e06db29a978bbf3ad3a5c52f6d0d97c64
[4] https://github.com/php/php-src/pull/15569#issuecomment-2354447087 https://github.com/php/php-src/pull/15569#issuecomment-2354447087ff
[5] https://wiki.php.net/rfc/support_object_type_in_bcmath https://wiki.php.net/rfc/support_object_type_in_bcmath
[6]https://github.com/php/php-src/commit/fad899e5662d0a929d8462dd8239b0489dd9b53f https://github.com/php/php-src/commit/fad899e5662d0a929d8462dd8239b0489dd9b53f
[7] https://github.com/php/php-src/issues/15968 https://github.com/php/php-src/issues/15968
[8] https://github.com/php/php-src/pull/16021 https://github.com/php/php-src/pull/16021

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 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 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 accepted
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

Am 2024-09-24 17:14, schrieb Christoph M. Becker:

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.

FWIW, there was a recent RFC to clarify what is acceptable in which
phase of the release process. Given that you did not vote there, I
believe you might have missed it:
https://wiki.php.net/rfc/release_cycle_update

I missed it while it was under discussion and in voting, but have read
it since then. And I almost fully agree to that RFC, except for the
issue at hand.

While I agree with Bob that by disallowing the RFC implementation during
the Betas would make Betas and RCs effectively identical. Nevertheless I
would like to see RFCs with a large impact voted on (and implemented)
well before the feature freeze, as the recent history required
following up with another RFC multiple times (e.g. Random Extension in
8.2, BCMath objects in 8.4, Property Hooks in 8.4). Asymmetric
visibility being voted on shortly before the freeze made me a little
uneasy for that reason.

I'm not suggesting to forbid new features during beta, but only to
forbid implementing RFCs during this time. While the implementation of
some RFCs would not be a big deal, we have to draw the line somewhere,
and I like to avoid additional discussions about which RFCs have a
"large impact", and which do not. But I don't necessarily want to be
too strict about that; for instance, PR #13578 has only been merged
after the first beta, although it was there for almost half a year, but
resolving the Windows test failures had not been done timely. So yeah,
some exceptions to the suggested rule would be fine for me.

See also Jakub's mail[1] with which I fully agree.

And yes, I fully agree about aviz having been very late.

[1] https://externals.io/message/125666#125688

Christoph