Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130323
Feedback-ID: id5114917:Fastmail
Date: Sun, 15 Mar 2026 10:33:34 +0000
To: internals@lists.php.net
Subject: =?US-ASCII?Q?Re=3A_=5BPHP-DEV=5D_=5BRFC=5D_php-community=3A_a?=
 =?US-ASCII?Q?_faster-moving=2C_community-driven_PHP=2E?=
User-Agent: K-9 Mail for Android
In-Reply-To: <839153A0-004D-4562-BD6E-65923201EDAA@gmail.com>
References: <839153A0-004D-4562-BD6E-65923201EDAA@gmail.com>
Message-ID: <299760A8-5C8A-41AD-B2EB-986079D41A47@rwec.co.uk>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 14 March 2026 18:32:24 GMT, Daniil Gentili <daniil=2Egentili@gmail=2Ecom=
> wrote:
>
>Submitting for discussion the php-community RFC, for a faster-moving, com=
munity-driven PHP: https://wiki=2Ephp=2Enet/rfc/php-community

Hi Daniil,

This sounds like a very ambitious idea, but I'm skeptical about both the w=
ork involved, and whether it will actually achieve its aim=2E


> For the first time, official binaries and packages will be provided for =
all major Linux distros for php-community releases on php=2Enet

Who is going to create and maintain these packages? Who decides which dist=
ros, which versions, etc? Like sandboxing, this could fill an RFC on its ow=
n=2E


> Multiple versions of the same feature may be offered at the same time in=
 a single php-community release

How will this work, code-wise? Are these versions actually separate implem=
entations side by side, or limited to changes that can be represented with =
feature flags?

What is the minimum lifetime and lifecycle of these versions? Can a versio=
n be retired early if it has an unsolvable stability or security issue?=20


> internals members through GitHub =F0=9F=91=8D =3D Accept, =F0=9F=91=8E =
=3D Reject, =F0=9F=91=80 =3D Abstain reactions on the issue using their Git=
Hub accounts,

I don't think we have any suitable definition of "internals members" that =
can apply here=2E Do you mean people with commit access to the php-src repo=
? Or are you hoping to cross-check GitHub users against main=2Ephp=2Enet ac=
counts (as used by the current voting widget) somehow?


>  A feature is eligible for removal only if both of the following conditi=
ons are met:
> -  It has no active maintainer listed in the accepted community RFC desi=
gn document=2E
> -  Adoption is negligible, as evidenced by Packagist statistics=2E

This feels incompatible with the rest of the process=2E If features are ea=
sy to propose, release, and iterate, it should be just as easy to mark them=
 abandoned or obsolete=2E Otherwise, an interesting but flawed feature has =
to be maintained forever even if its author loses interest - and who is goi=
ng to do that maintenance?

If the intention of these features is to be experimental, perhaps every fe=
ature version could have a fixed lifetime=2E Users know that they can't rel=
y on it long-term, but if it's popular it will hopefully make it into a sta=
ble release of PHP=2E


> php-community will always be based on the latest stable PHP release

Who will be responsible for merging changes made to "feature extensions" b=
ack to master, and stabilising the first community release after a new stab=
le release?


> Community releases are =E2=80=9Chandled=E2=80=9D by the same release man=
agers of the latest stable PHP release, however the release process will be=
 significantly automated, compared to the current manual release process

Is there something that makes this automation easier for community release=
s than regular ones? Or is automaton of the existing process something that=
 needs to be done before we can consider this RFC?


> Wait for the CI status of the new branch to become green

If there are failing tests in a particular feature when it's time to tag a=
 community release, what happens? Does the release get delayed until the ma=
intainer of that feature fixes it?


> php-community will live on a new community branch of php-src

Who will be responsible for the stability of this branch? This is really i=
mportant, because you're targeting this concept at shared hosts, who want t=
o know the software they're running is stable and secure=2E

Why will somebody trust this branch containing a bunch of separately-maint=
ained feature extensions any more than they would trust a repository of PIE=
 extensions? If anything, it is far *more* dangerous, because the features =
aren't limited to the normal extension API=2E


 > Note: the first community RFC may indeed be the one regarding the choic=
e of appropriate sandbox keys=2E

By definition, the sandbox mechanism needs to exist outside of the feature=
 extension system, and be stable across community versions=2E As others hav=
e said, it's basically independent of this proposal, and should be its own =
RFC following the normal process=2E


In other replies on this thread you've emphasised the role of feature main=
tainers, but the RFC doesn't go into much detail about how that role will w=
ork=2E Will it be like maintaining a PIE extension, committing code directl=
y, but in a directory of php-src? Or are other members of the community exp=
ected to review their code and merge it?


I think this RFC is trying to do two conflicting things at once:=20

1) allow users to test far-reaching, experimental, changes to the language=
 and engine
2) allow users to enable safe, stable, features without installing untrust=
ed binaries

For problem 1, what we need is a way to get usable builds into the hands o=
f users from experimental branches of the source=2E If CI tooling and relea=
se packaging can be automated enough, there's no reason to limit it to just=
 one "community" branch=2E

For problem 2, we need stronger guarantees of stability, not weaker ones: =
better sandboxing so people trust extensions more, perhaps; or more feature=
 flags within the existing release cycle=2E


There's some interesting ideas in here, but I don't think they're workable=
 as presented=2E


Rowan Tommins
[IMSoP]