Hi Daniil Thanks for your response.
On Sun, Mar 15, 2026 at 2:45 AM Daniil Gentili <[email protected]> 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
