Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119565
Message-ID: <0bd51c13-5d97-ac0d-8a96-d05425b41cc2@bastelstu.be>
Date: Thu, 16 Feb 2023 17:52:14 +0100
MIME-Version: 1.0
Content-Language: en-US
To: Max Kellermann <max+php@blarg.de>, Derick Rethans <derick@php.net>
Cc: internals@lists.php.net
References: <Y9pXdfDdYqnzwnIt@swift.blarg.de>
 <Y+z3x/QgwL7/9bRb@swift.blarg.de>
 <97F04371-A963-4A82-80E0-A94A4DC5B794@php.net>
 <Y+3pG6JJhaGNx7JK@swift.blarg.de>
In-Reply-To: <Y+3pG6JJhaGNx7JK@swift.blarg.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] include cleanup RFC declined
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 2/16/23 09:28, Max Kellermann wrote:
>> Secondary votes are irrelevant if the primary one doesn't pass.
> 
> You may be formally correct (or maybe not, because
> https://wiki.php.net/rfc/voting doesn't really say that).
> 
> In any case, a vote that reaches supermajority (i.e. it would have
> been accepted if it had been a separate RFC) is an unambiguous
> expression on how the community wants the PHP source code to look
> like.

Not necessarily. It might've been the case that a voter believes that 
include cleanups should not happen, but at the same time believes that 
*if* cleanups happen, then splitting a header is a natural part of such 
a cleanup.

The same is true for the secondary vote of the include comments. My 
understanding is that the primary concern of the "no" votes is the churn 
in the code base. Removing the existing include comments will just 
create additional churn and provide no value-add at all. It is perfectly 
possible to be both against "include comments" and "actively remove 
include comments".

That said I can only summarize the entire RFC, vote and result as 
"unfortunate".

As I've said in my previous email from Feb 9, as a maintainer I'm not 
sure what a "declined vote" effectively means for me, because the RFC 
text and vote description is pretty broad and unspecific. May I perform 
a scoped clean up within a single extension (ext/random in my case)? May 
I not? Do I need an explicit RFC? I feel like the vote actually made the 
situation less clear for me.

Without this RFC I might've just proposed a PR in the future, made sure 
to check that I don't unnecessarily break compatibility, requested two 
or three reviews and it would likely have been approved, merged and 
shipped with whatever version comes next. Now it is much less obvious 
what to do or not to do.

Best regards
Tim Düsterhus