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