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

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: 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. > > 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 :) 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.