Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130369
Content-Type: text/plain;
	charset=utf-8
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
Subject: Re: [PHP-DEV] [RFC] php-community: a faster-moving, community-driven
 PHP.
In-Reply-To: <CAPyj-LAxM080uWEWMdzOgFU3dbUkkM39hbcoSiJEqetiK+LksQ@mail.gmail.com>
Date: Mon, 16 Mar 2026 18:58:27 +0100
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <E3AE38E4-F510-4DD9-94DC-866340579AA4@gmail.com>
References: <839153A0-004D-4562-BD6E-65923201EDAA@gmail.com>
 <CAPyj-LAajGgbhtibKGpWkM6TpHM2mNW68h=pUW81bC+-PaGzpg@mail.gmail.com>
 <CAKXKfQv66oqPmH-_wG726PR4zb3sk-mKmwh=redooeq8CmD9kw@mail.gmail.com>
 <CAPyj-LAxM080uWEWMdzOgFU3dbUkkM39hbcoSiJEqetiK+LksQ@mail.gmail.com>
To: Ilija Tovilo <tovilo.ilija@gmail.com>
From: daniil.gentili@gmail.com (Daniil Gentili)

Hi Ilija,

> On Sun, Mar 15, 2026 at 2:45=E2=80=AFAM Daniil Gentili =
<daniil.gentili@gmail.com> wrote:
>>=20
>> 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.
>=20
> 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.
>=20
> 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?
>=20

Thanks for your feedback, indeed removal could be handled better.

Updated the removal policy in 1.1.0 based on your feedback: =
https://wiki.php.net/rfc/php-community#section110


>> 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.
>=20
> 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=E2=80=99s 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.

>=20
>>> There's no real veto for php-src maintainers, a single internals
>>> member can overrule the "veto" mentioned in the RFC.
>>=20
>> No, that is not correct, a single internals member cannot overrule a =
veto made by all remaining internals members.
>>=20
>> Only 50%+1 internals members put together can overrule a veto made by =
the remaining half.
>=20
> 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.

>=20
>>> If a problematic
>>> feature is accepted, it must be supported for at least 6 months,
>>=20
>> By the feature owner, not php-src maintainers (again, like with =
Linux).
>=20
> 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.
>=20

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 :)


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.=20

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.=