On Wed, Mar 1, 2023 at 8:15 AM Max Kellermann <max+...@blarg.de> wrote:
> On 2023/03/01 06:37, Max Kellermann <max+...@blarg.de> wrote: > > Indeed it appears Dmitry is right - code refactoring is generally NOT > > allowed (unless there is an explicit RFC vote, and I havn't seen one). > > IMO this is a bug in the process, and I'm trying to fix it. It should > be allowed to merge small incremental improvements without a dedicated > RFC. > > This is the first draft of my RFC: > https://wiki.php.net/rfc/code_optimizations > > Let's discuss. > > Max > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > 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. -- Marco Deleu
