Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119518
MIME-Version: 1.0
References: <Y9pXdfDdYqnzwnIt@swift.blarg.de> <1cb213ea-ff7d-c4b2-5345-fadbc5953c94@bastelstu.be>
 <Y+VKekLm+PTaEG7y@swift.blarg.de>
In-Reply-To: <Y+VKekLm+PTaEG7y@swift.blarg.de>
Date: Thu, 9 Feb 2023 16:09:28 -0600
Message-ID: <CAJp_myV3MOoGckgBr0f8-0nhiUWkLJ8Bt_Z3apzsJH7i+ePY3Q@mail.gmail.com>
To: Max Kellermann <max+php@blarg.de>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000015774705f44ba39c"
Subject: Re: [PHP-DEV] [VOTE] include cleanup
From: mweierophinney@gmail.com ("Matthew Weier O'Phinney")

--00000000000015774705f44ba39c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 9, 2023 at 1:33 PM Max Kellermann <max+php@blarg.de> wrote:

> On 2023/02/09 19:04, Tim D=C3=BCsterhus <tim@bastelstu.be> wrote:
> > However based on the discussion of the RFC I believe that voters may ha=
ve
> > assumed that a "No" means "A cleanup is not allowed", because several
> > participants expressed an active aversion to a cleanup during the
> > discussion. As for myself I've certainly had that understanding when
> casting
> > my vote.
>
> Voting "NO" means no change - and currently, cleanup is not allowed,
> which you can see from the fact that all of my code cleanups were
> either rejected or reverted.
>

That's a poor interpretation of what happened.

As Tim alluded, the current status quo is that cleanup is allowed on a
case-by-case basis. The particular cases resulting from your PRs were
rejected, but this doesn't mean all cases will be.

I'm not directly involved in maintenance, but my take on the scenario was
that these were rejected and reverted because they caused breakage, whether
that was in compiling a spare PHP build, or in extensions that were
assuming that using certain headers would slurp in everything they needed.
This breakage was unacceptable without an RFC. I saw chatter from a number
of folks after the changes were merged about builds no longer compiling;
considering the stability of the php-src tree, inability to build will
always be a source of alarm.

What needs clarification in the RFC you've presented is that a "No" vote
means "no change to current processes". Personally, I'd halt the current
vote, make the change, and re-start the vote at this point to ensure
everyone voting is clear on that point.


> > Disallowing a clean-up would require 33% of votes, whereas allowing
> > clean-up would require 66% of votes. The status quo "decide on a
> > case by case basis" would no longer be legal even without a clear
> > agreement.
>
> It is indeed unfortunate that a supermajority is required for all
> primary votes, because in this case, requiring only a simple majority
> would be favorable IMO.
>

A supermajority is required on any change that would lead to backwards
incompatibility for either end-users or extension writers. Your proposal is
something that would do the latter. Sure a simple majority is ALWAYS more
favorable, but the hurdle exists to ensure that everyone pay attention to
the BC implications when they vote.


> It is not clear whether the current rule is "decide on a case by case
> basis"; it has been argued that my code cleanup shall be
> rejected/reverted because that would make merging branches harder.
>
> - If that alone is reason enough to reject/revert a code cleanup
>   change, then this applies to all kinds of code cleanup, and no code
>   cleanup is currently allowed.  -> "case by case" doesn't count.
>
> - If that alone is NOT reason enough to reject/revert a code cleanup,
>   then more reasons need to be brought forward to hold my code
>   cleanups off.
>

As I pointed out earlier, the changes previously merged led to breakages
when compiling the project. How is that not enough? And dumping a huge
bunch of PRs with such changes without first discussing it with maintainers
means a lot of effort reviewing =E2=80=94 why are your proposed changes mor=
e
important than any of the other work the various maintainers are doing?
This is why they asked for an RFC; something of this magnitude needs
discussion, because it impacts everybody already touching the project, the
people most familiar with it.

The other point that has been brought up multiple times is that it
introduces breaking changes for extension maintainers.

Should these extensions be relying on one or more "god" headers instead of
the specific headers for the symbols they use? Probably not. Will forcing
the issue without giving them a chance to review and understand the
changes, and have a roadmap for when and how those changes occur be a net
positive? No; it will cause a lot of busy work for a lot of people, almost
all of whom are volunteers and most of whom would rather be building out
user-requested features or fixing user-reported bugs.

I'm unsure why that's unclear or not enough for you.

--=20
Matthew Weier O'Phinney
mweierophinney@gmail.com
https://mwop.net/
he/him

--00000000000015774705f44ba39c--