Re: [PHP-DEV] [RFC] php-community: a faster-moving, community-driven PHP.

Mailing Lists php.internals
1

Hi Daniil

On Sat, Mar 14, 2026 at 7:32 PM Daniil Gentili <daniil.gentili@gmail.com> wrote:

Submitting for discussion the php-community RFC, for a faster-moving, community-driven PHP: PHP: rfc:php-community

I understand and appreciate your desire to accelerate the development
speed of PHP. However, this proposal would put a completely
unrealistic burden on php-src maintainers.

By design, it would become very easy to add new features to the
community branch. However, code isn't merged and forgotten; it
requires continued maintenance. Features interact, bugs need to be
fixed, code will diverge from release branches and require conflict
resolution, development of features through PRs would still require
reviews by maintainers, etc. The additional effort to keep all of this
working correctly for underspecified and questionable features would
be immense.

There's no real veto for php-src maintainers, a single internals
member can overrule the "veto" mentioned in the RFC. If a problematic
feature is accepted, it must be supported for at least 6 months,
further burden falls on php-src maintainers to propose the removal of
the problematic feature, and it might not even be removed unless:

Adoption is negligible, as evidenced by Packagist statistics.

I honestly think this would be catastrophic.

I think this development model works much better with authoritative
working groups or a benevolent dictator, along with a coherent
roadmap. And crucially, failed ideas would be removed before this
community edition becomes a cemetery of failed ideas.

Ilija

2

Submitting for discussion the php-community RFC, for a faster-moving, community-driven PHP: https://wiki.php.net/rfc/php-community

I understand and appreciate your desire to accelerate the development
speed of PHP. However, this proposal would put a completely
unrealistic burden on php-src maintainers.

By design, it would become very easy to add new features to the
community branch. However, code isn’t merged and forgotten; it
requires continued maintenance. Features interact, bugs need to be
fixed, code will diverge from release branches and require conflict
resolution, development of features through PRs would still require
reviews by maintainers, etc. The additional effort to keep all of this
working correctly for underspecified and questionable features would
be immense.

As mentioned in the RFC and earlier in the thread, the burden of maintaining feature extensions will lay exclusively on the owners of the community RFCs, and any other maintainers appointed by them.

Features and bug fixes for feature extensions will NOT be a responsibility of php-src maintainers.
This also includes reviews on feature extension code, which will be a exclusive responsibility of the owners of said features.

In other words, feature extensions are “guests” allowed into the php-community branch, and are developed and maintained exclusively by their owners just as if they were a standalone extension.

Of course, a more detailed review on behalf of php-src maintainers is still preferable for the initial addition PR, but it is not required (even if obviously still allowed) for subsequent PRs.

There’s no real veto for php-src maintainers, a single internals
member can overrule the “veto” mentioned in the RFC.

No, that is not correct, a single internals member cannot overrule a veto made by all remaining internals members.

Only 50%+1 internals members put together can overrule a veto made by the remaining half.

If a problematic
feature is accepted, it must be supported for at least 6 months,

By the feature owner, not php-src maintainers (again, like with Linux).

further burden falls on php-src maintainers to propose the removal of
the problematic feature, and it might not even be removed unless:

Adoption is negligible, as evidenced by Packagist statistics.

To be honest, this is not all too different from the current state of PHP: there is a large amount of extension code in core which are only there because it was added a long time ago to cover a specific usecase, and is still there even if technology has moved on and that feature is no longer in use by the majority of the PHP userbase (thinking about legacy db drivers).

In php-community, actual, real adoption statistics will be available through packagist, making removal actually a lot easier.

I think this development model works much better with authoritative
working groups or a benevolent dictator, along with a coherent
roadmap. And crucially, failed ideas would be removed before this
community edition becomes a cemetery of failed ideas.

I partially agree, and partially disagree.

Go indeed does have a few benevolent dictators that get the final words in case the various committees cannot find an agreement: this has worked out mostly well for them, but unlike processes, a benevolent dictator is not something that can be easily copied.

I personally cannot think of a single person that can be entrusted with the role of a benevolent dictator for PHP.

On the contrary, I believe that the current status quo of PHP is “a bunch of dictators with largely varying opinions” is actually a good thing, because internals members fight it out in full transparency, in a public mailing list, presenting a variety of viewpoints and arguments.

The only missing thing, which is the main reason why I made this RFC, is real adoption data and feedback from the community that can be used to empower or defeat viewpoints during the public internals argument.

The definition of “failed ideas” should not be up to any single internals member to decide, it should be up to the actual users, who actually get to use the language every day.

Regards,
Daniil Gentili.

3

Hello!

However, this proposal would put a completely unrealistic burden on php-src maintainers.

It seems to me this is an organizational problem that certainly has a
good solution.
In my company we also use something similar.
In practice it does not require that much effort. Moreover, right now
I am doing essentially the same thing for the TrueAsync project:

- the php-src code is updated
- tests are run
- if the tests pass, the code proceeds further

I am doing this manually, although the process could be automated.
TrueAsync currently has about 18,000+ lines of changes in PHP-SRC.
Over these six months my personal attention was required only 2–3
times. I can confirm a similar experience with other projects as well.
A large number of different solutions can be devised here, both at the
level of flow and rules, and at the level of technical approaches. So
yes, it is a problem.
But it is a problem that has a solution.

There's no real veto for php-src maintainers,

This question is more complex. I personally prefer the models used by
Go and Python, which rely on consensus rather than voting. I would
only add a long path of iterative development, where a feature reaches
users at an early stage. Releasing a feature early is what provides
quality guarantees, something that is well confirmed by modern IT
practice.
Building a quality product using the scheme “first we design an RFC
here → then nobody can actually implement it” has historically not
worked well. Companies spent millions of dollars on this approach in
the 1960s–70s, and the percentage of successful projects built this
way was extremely small.

This applies not only to the async project. Generics and most
moderately complex features are in the same boat.

I honestly think this would be catastrophic.

Not impossible. Although using statistics and real-world usage to
evaluate features is definitely useful. The question is how to use it
most effectively.
I think this requires some thought.

Best regards, Ed

4

On 3/15/26 04:17, Edmond Dantes wrote:

Hello!

However, this proposal would put a completely unrealistic burden on php-src maintainers.

It seems to me this is an organizational problem that certainly has a
good solution.
In my company we also use something similar.
In practice it does not require that much effort. Moreover, right now
I am doing essentially the same thing for the TrueAsync project:

- the php-src code is updated
- tests are run
- if the tests pass, the code proceeds further

I am doing this manually, although the process could be automated.
TrueAsync currently has about 18,000+ lines of changes in PHP-SRC.
Over these six months my personal attention was required only 2–3
times. I can confirm a similar experience with other projects as well.
A large number of different solutions can be devised here, both at the
level of flow and rules, and at the level of technical approaches. So
yes, it is a problem.
But it is a problem that has a solution.

I worked on an automated release workflow[^1] for php-src a few years ago, but after discussions with others from various major project communities (including Apache, Linux, etc.), I realized the solution wasn't workable for one main reason:

An automated workflow cannot sign builds and still be considered secure.

Builds must be signed by a human on the machine where the build took place. Automating the signatures in the cloud significantly reduces trust and greatly increases the likelihood of a bad actor gaining access to sneak things into the build (e.g., through compromised GitHub Actions, etc.).

This was the nearly universal advice I was given by folks from other communities in 2023. I doubt that it's changed much since then, and especially with the rise of software supply chain attacks, it's probably even more relevant today.

Cheers,
Ben

[^1]: Implement automated release workflow for GitHub Actions by ramsey · Pull Request #10604 · php/php-src · GitHub

5

I worked on an automated release workflow[^1] for php-src a few years
ago, but after discussions with others from various major project
communities (including Apache, Linux, etc.), I realized the solution
wasn’t workable for one main reason:

An automated workflow cannot sign builds and still be considered secure.

Builds must be signed by a human on the machine where the build took
place. Automating the signatures in the cloud significantly reduces
trust and greatly increases the likelihood of a bad actor gaining access
to sneak things into the build (e.g., through compromised GitHub
Actions, etc.).

I strongly disagree.

I have way more trust in an automatic build environment with reproducible (key word here) builds than in a (potentially corruptible) human that pinkie swears no changes were made to an autogenerated configure contained in released tarballs.

6

An automated workflow cannot sign builds and still be considered secure

Thank you for pointing out this aspect. However, my message was about
something slightly different.

7

On 3/15/26 09:55, Daniil Gentili wrote:

I worked on an automated release workflow[^1] for php-src a few years
ago, but after discussions with others from various major project
communities (including Apache, Linux, etc.), I realized the solution
wasn't workable for one main reason:

An automated workflow cannot sign builds and still be considered secure.

Builds must be signed by a human on the machine where the build took
place. Automating the signatures in the cloud significantly reduces
trust and greatly increases the likelihood of a bad actor gaining access
to sneak things into the build (e.g., through compromised GitHub
Actions, etc.).

I strongly disagree.

I have way more trust in an automatic build environment with reproducible
(key word here) builds than in a (potentially corruptible) human that
pinkie swears no changes were made to an autogenerated configure contained
in released tarballs.

That's why the builds are signed, and the keys used to sign the builds are also signed by other, trusted parties. If the human who builds it introduces any changes, we can trace it directly to them because they signed that build. If their key was compromised, they revoke the key, and the build's signature now shows as valid but using a revoked key, so others know not to trust it.

Cheers,
Ben

8

Hi Daniil

Thanks for your response.

On Sun, Mar 15, 2026 at 2:45 AM Daniil Gentili <daniil.gentili@gmail.com> wrote:

As mentioned in the RFC and earlier in the thread, the burden of maintaining feature extensions will lay exclusively on the owners of the community RFCs, and any other maintainers appointed by them.
Features and bug fixes for feature extensions will NOT be a responsibility of php-src maintainers.

In practice, many people propose one RFC and then move on to some
other project. I think it's an unrealistic expectation that they will
stick around for maintenance.

In the likely case that the original proposer stops maintaining the
feature, it cannot be removed if it has been adopted by users,
according to this RFC. So the code will sit around and rot, and the
feature might break completely. Will end-users understand this
distinction or blame the PHP Foundation for not fixing their issues?
Will they blame us for degrading quality?

In other words, feature extensions are "guests" allowed into the php-community branch, and are developed and maintained exclusively by their owners just as if they were a standalone extension.

But this code doesn't live in isolation. If it would, the feature
could just be added to an extension and the problem would be solved.
But many features require changes to the engine, which is prone to
bugs, performance regressions and security issues that impact the
whole system. If this code is changed by guests and not reviewed by
maintainers, how do we prevent the community edition from constantly
breaking, or backdoors from being added by unknown people? Who will
merge changes and bug fixes from the stable branches and master? Who
will fix interactions between community-only features? Or as Jakub
mentioned, who will handle security issues? These are several
full-time jobs.

There's no real veto for php-src maintainers, a single internals
member can overrule the "veto" mentioned in the RFC.

No, that is not correct, a single internals member cannot overrule a veto made by all remaining internals members.

Only 50%+1 internals members put together can overrule a veto made by the remaining half.

FWIU, if the community votes are all upvotes (which is not rare for
GitHub, the community is more enthusiastic and optimistic than
internals), a single upvote from an internals person will reach the
50+% threshold. It's also worth noting that GitHub Upvotes can be
bought.

If a problematic
feature is accepted, it must be supported for at least 6 months,

By the feature owner, not php-src maintainers (again, like with Linux).

Linus also has a special authority over Linux. He has removed
components in the past over disagreements. Nobody in the PHP community
has this kind of authority.

further burden falls on php-src maintainers to propose the removal of
the problematic feature, and it might not even be removed unless:

> Adoption is negligible, as evidenced by Packagist statistics.

To be honest, this is not all too different from the current state of PHP: there is a large amount of extension code in core which are only there because it was added a long time ago to cover a specific usecase, and is still there even if technology has moved on and that feature is no longer in use by the *majority* of the PHP userbase (thinking about legacy db drivers).

Yes, this is absolutely true. And that's also why the RFC threshold
was increased to 2/3s, and why new additions are heavily scrutinized.
I understand that this can be incredibly frustrating (I was in that
boat myself many times) but it's also true that undoing mistakes is
much harder than not making the mistake in the first place.

Ilija

9

Version 1.1.0 of the RFC was published:

#### 1.1.0

- **Voting (clarification)** — Clarified that only internals members with voting rights count for quorum/veto calculations, and emphasized internals-only quorum wording.

- **Community RFC owners (clarification)** — Clarified that compatibility fixes caused by breaking internal PHP API changes are handled by whoever introduces those breaking changes.

- **Removal of community RFC features (policy update)**

Removal voting remains open to all for sentiment, but only internals votes are counted for outcome.

Eligibility changed from strict `AND` conditions to an `OR` policy:
- no active owners (defined as no commits and no replies from listed owners in 6 months; with owner removal possible in case of violations);
- or negligible adoption, based on Packagist stats/telemetry.

Deprecation period after acceptance of a removal RFC was reduced from at least 3 stable `php-community` releases to at least 1 stable release.

- **Feature extensions (new clarifications)** — Added guidance that releases should ideally ship all major versions of feature extensions together, that security updates apply to all currently shipped versions, and that retiring old majors is up to feature owners based on adoption.

10

Hi Ilija,

On Sun, Mar 15, 2026 at 2:45 AM Daniil Gentili <daniil.gentili@gmail.com> wrote:

As mentioned in the RFC and earlier in the thread, the burden of maintaining feature extensions will lay exclusively on the owners of the community RFCs, and any other maintainers appointed by them.
Features and bug fixes for feature extensions will NOT be a responsibility of php-src maintainers.

In practice, many people propose one RFC and then move on to some
other project. I think it's an unrealistic expectation that they will
stick around for maintenance.

In the likely case that the original proposer stops maintaining the
feature, it cannot be removed if it has been adopted by users,
according to this RFC. So the code will sit around and rot, and the
feature might break completely. Will end-users understand this
distinction or blame the PHP Foundation for not fixing their issues?
Will they blame us for degrading quality?

Thanks for your feedback, indeed removal could be handled better.

Updated the removal policy in 1.1.0 based on your feedback: PHP: rfc:php-community

In other words, feature extensions are "guests" allowed into the php-community branch, and are developed and maintained exclusively by their owners just as if they were a standalone extension.

But this code doesn't live in isolation. If it would, the feature
could just be added to an extension and the problem would be solved.
But many features require changes to the engine, which is prone to
bugs, performance regressions and security issues that impact the
whole system. If this code is changed by guests and not reviewed by
maintainers, how do we prevent the community edition from constantly
breaking, or backdoors from being added by unknown people? Who will
merge changes and bug fixes from the stable branches and master? Who
will fix interactions between community-only features? Or as Jakub
mentioned, who will handle security issues? These are several
full-time jobs.

I am fully aware that this is a lot of work.

It is the work of language maintainers, it’s what they do, and I understand that adding more to your already full plates can be a problem.

However, as I mentioned earlier, appropriate workload reprioritisation in favour of php-community would be an investment into future PHP and PHPF funding growth.

There's no real veto for php-src maintainers, a single internals
member can overrule the "veto" mentioned in the RFC.

No, that is not correct, a single internals member cannot overrule a veto made by all remaining internals members.

Only 50%+1 internals members put together can overrule a veto made by the remaining half.

FWIU, if the community votes are all upvotes (which is not rare for
GitHub, the community is more enthusiastic and optimistic than
internals), a single upvote from an internals person will reach the
50+% threshold. It's also worth noting that GitHub Upvotes can be
bought.

No, only internals votes count towards the veto, clarified this.

If a problematic
feature is accepted, it must be supported for at least 6 months,

By the feature owner, not php-src maintainers (again, like with Linux).

Linus also has a special authority over Linux. He has removed
components in the past over disagreements. Nobody in the PHP community
has this kind of authority.

Well, just for php-community, I suppose a benevolent dictator might be chosen.

I believe you could fit the role, if you would be unavailable for this I could step in :slight_smile:

Anyway, as a disclaimer, I fully intend to push php-community and true async ONLY with the agreement of internals and the phpf.

Even in our different views, we all care about PHP in different ways: I respect this, and I have absolutely no intention to just make a new fork of PHP (and I have advised Edmond against doing this as well for True Async).

I want the best for PHP.

For this to work, I will only proceed with the consensus of internals, who are all historical figures in PHP, each one has contributed a lot to this language.

Kind regards,
Daniil Gentili.