RFC: code optimizations

On Wed, Mar 1, 2023 at 8:15 AM Max Kellermann <max+php@blarg.de> wrote:

I'm not a voter, but my two cents anyway, as that's the point of internals. Seems like there could be a historical reason this is the way it is. The RFC process involves proposing changes to the PHP language that has an impact on: - Core Developers - Extension Developers - Documentation - Release Managers - Libraries and Frameworks - Users of PHP - Server Admins (potentially) As such, the RFC process exists to provide the possibility of involvement of a larger community. Changes to existing code in the way that is described on this RFC has a direct impact on Core Developers and maybe Extension Developers and nobody else. I'm guessing the RFC process has never been used for it before because it mainly involves the folks developing the language itself and has no direct impact on everyone else. If Core Developers can agree, review and approve each other's code change, no RFC has ever been necessary. The problem now is that there's a dispute between core developers and there doesn't seem to be a way to resolve such dispute. The downside of this RFC is that it opens up the discussion of how to write internal code for PHP to a larger community that has no strong involvement in it with more potential to harm than improvements. All in all, Dmitry, Max and other core developers could try to find common ground, understand each other and see past the issue at hand. The language could always benefit from having more core contributors instead of less, so perhaps there's something that can be done so Max can feel more welcome. In contrast, a decade's worth of internal contributions from Dmitry shouldn't be dismissed and Max could try to better understand where Dmitry is coming from. I think a lot of senior developers can sympathise when new developers full of energy join the team and want to make drastic changes everywhere. It can feel like a golden retriever making a mess. But a fresh perspective and a diverse mindset can often find new solutions and improve the project in the long-term. Krakjoe and The PHP Foundation is trying to reduce the bus factor of PHP and Max is one way of achieving that. In conclusion, I don't think this RFC should move forward but if it does, it would be important for every voter to think whether this has a direct impact on their contribution to PHP or if it should be something left for folks that have skin in the game to decide. One last thing: if Max's change can be beneficial to the project, but are causing other issues such as merge conflicts or breaking stuff, send these stuff to him and ask him to see for himself the consequences of his changes. Maybe he can decide for himself that reverting is the best approach or maybe he can use his energy to fix even deeper issues.

The current amount of secondary votes makes it feel daunting. I would suspect not all voters will think thoroughly about each of the questions. I suggest that most of these questions could be agreed upon in discussions before the vote. Maybe the RFC could propose a certain wording of the guidelines? The community could then agree on most details via a discussion. And the vote question would turn from "should x be allowed?" to "change guidelines to the proposed ones?" which might feel less abstract for most voters. Of course, secondary votes might still have their place, but only for the contentious questions where there is no consensus. Regards, Juris

On 2023/03/01 13:15, Max Kellermann <max+php@blarg.de> wrote:

My RFC draft is hereby withdrawn. I no longer intend to upstream my PHP improvements. Sorry for the noise. Max