Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130358
Precedence: list
MIME-Version: 1.0
References: <839153A0-004D-4562-BD6E-65923201EDAA@gmail.com>
 <CAPyj-LAajGgbhtibKGpWkM6TpHM2mNW68h=pUW81bC+-PaGzpg@mail.gmail.com> <CAKXKfQv66oqPmH-_wG726PR4zb3sk-mKmwh=redooeq8CmD9kw@mail.gmail.com>
In-Reply-To: <CAKXKfQv66oqPmH-_wG726PR4zb3sk-mKmwh=redooeq8CmD9kw@mail.gmail.com>
Date: Sun, 15 Mar 2026 18:42:44 +0100
Message-ID: <CAPyj-LAxM080uWEWMdzOgFU3dbUkkM39hbcoSiJEqetiK+LksQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] php-community: a faster-moving, community-driven PHP.
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Daniil

Thanks for your response.

On Sun, Mar 15, 2026 at 2:45=E2=80=AFAM Daniil Gentili <daniil.gentili@gmai=
l.com> wrote:
>
> As mentioned in the RFC and earlier in the thread, the burden of maintain=
ing 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 responsibilit=
y 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-comm=
unity 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 be=
cause it was added a long time ago to cover a specific usecase, and is stil=
l there even if technology has moved on and that feature is no longer in us=
e 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