On 14 March 2026 18:32:24 GMT, Daniil Gentili <[email protected]> wrote: > >Submitting for discussion the php-community RFC, for a faster-moving, >community-driven PHP: https://wiki.php.net/rfc/php-community
Hi Daniil, This sounds like a very ambitious idea, but I'm skeptical about both the work involved, and whether it will actually achieve its aim. > For the first time, official binaries and packages will be provided for all > major Linux distros for php-community releases on php.net Who is going to create and maintain these packages? Who decides which distros, which versions, etc? Like sandboxing, this could fill an RFC on its own. > 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 implementations 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 version be retired early if it has an unsolvable stability or security issue? > internals members through GitHub π = Accept, π = Reject, π = Abstain > reactions on the issue using their GitHub accounts, I don't think we have any suitable definition of "internals members" that can apply here. Do you mean people with commit access to the php-src repo? Or are you hoping to cross-check GitHub users against main.php.net accounts (as used by the current voting widget) somehow? > A feature is eligible for removal only if both of the following conditions > are met: > - It has no active maintainer listed in the accepted community RFC design > document. > - Adoption is negligible, as evidenced by Packagist statistics. This feels incompatible with the rest of the process. If features are easy to propose, release, and iterate, it should be just as easy to mark them abandoned or obsolete. Otherwise, an interesting but flawed feature has to be maintained forever even if its author loses interest - and who is going to do that maintenance? If the intention of these features is to be experimental, perhaps every feature version could have a fixed lifetime. Users know that they can't rely on it long-term, but if it's popular it will hopefully make it into a stable release of PHP. > php-community will always be based on the latest stable PHP release Who will be responsible for merging changes made to "feature extensions" back to master, and stabilising the first community release after a new stable release? > Community releases are βhandledβ by the same release managers 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 releases 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 maintainer 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 important, because you're targeting this concept at shared hosts, who want to know the software they're running is stable and secure. Why will somebody trust this branch containing a bunch of separately-maintained 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. > Note: the first community RFC may indeed be the one regarding the choice of > appropriate sandbox keys. By definition, the sandbox mechanism needs to exist outside of the feature extension system, and be stable across community versions. As others have said, it's basically independent of this proposal, and should be its own RFC following the normal process. In other replies on this thread you've emphasised the role of feature maintainers, but the RFC doesn't go into much detail about how that role will work. Will it be like maintaining a PIE extension, committing code directly, but in a directory of php-src? Or are other members of the community expected to review their code and merge it? I think this RFC is trying to do two conflicting things at once: 1) allow users to test far-reaching, experimental, changes to the language and engine 2) allow users to enable safe, stable, features without installing untrusted binaries For problem 1, what we need is a way to get usable builds into the hands of users from experimental branches of the source. If CI tooling and release packaging can be automated enough, there's no reason to limit it to just one "community" branch. 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. There's some interesting ideas in here, but I don't think they're workable as presented. Rowan Tommins [IMSoP]
