Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119640
MIME-Version: 1.0
References: <Y/9B2dE8JY2E4cEG@swift.blarg.de>
In-Reply-To: <Y/9B2dE8JY2E4cEG@swift.blarg.de>
Date: Wed, 1 Mar 2023 11:48:54 -0400
Message-ID: <CADK1yXJzzj=vA8Y030ws9bu0+hoiFNOWa3nhsr8h4VO9_BA5bg@mail.gmail.com>
To: Max Kellermann <max+php@blarg.de>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005c303105f5d8a8c2"
Subject: Re: [PHP-DEV] RFC: code optimizations
From: deleugyn@gmail.com (Deleu)

--0000000000005c303105f5d8a8c2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 1, 2023 at 8:15=E2=80=AFAM Max Kellermann <max+php@blarg.de> wr=
ote:

> On 2023/03/01 06:37, Max Kellermann <max+php@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.

--=20
Marco Deleu

--0000000000005c303105f5d8a8c2--