Re: [PHP-DEV] include cleanup RFC declined
On 2023/02/16 17:52, Tim Düsterhus wrote: > 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. Maybe, but that seems unlikely to me. 1. There is exactly one person who voted "NO" to the primary vote but "YES" to splitting headers. 2. If include cleanups happen, then splitting headers is the only proposed change that is likely to ever cause a merge conflict. If somebody fears "code churn", it wouldn't make sense to accept splitting headers as "natural part". I trust that the voters knew what they were voting for, and if there's a supermajority for splitting headers, then that's the will of the community. > It is perfectly possible to be both against "include comments" and > "actively remove include comments". What you're replying to is just explaining why I believe the secondary votes are not "irrelevant". Your reply doesn't disagree with that, it only speculates how some hypothetical reviewer could reasonably argue to reject PR 10472. That misses the point I tried to make, and I'd rather wait for those hypothetical reviewers to post actual reviews. There hasn't been any so far, even though I posted the PR before voting even began. > I feel like the vote actually made the situation less clear for me. Yes, I feel the same. Requiring a supermajority for this kind of decision doesn't appear to make sense. For some intrusive changes, requiring a supermajority makes sense (if there are serious downsides for the "losing" minority), but IMO not here. The downsides are as minimal as they can be. We're now in a situation where the majority of voters want the code cleanup, but the fact that I asked for the vote made it LESS likely that the majority gets what they want. That is backwards! The cast of a vote must never worsen the situation for the majority. Max -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] include cleanup RFC declined
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] include cleanup RFC declined
On 2023/02/16 08:59, Derick Rethans 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. It is safe to say that the PHP community doesn't want any include comments and forward declarations, but wants to split large headers in order to reduce header dependencies. I guess we both don't like the outcome of the vote (for different reasons), but let's not start lawyering pointlessly, and accept the community's will. Max -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] include cleanup RFC declined
On 15 February 2023 15:18:31 GMT, Max Kellermann wrote:
>On 2023/02/01 13:13, Max Kellermann wrote:
>> Voting starts now, please vote on my RFC:
>> https://wiki.php.net/rfc/include_cleanup
>
>Hi,
>
>voting of https://wiki.php.net/rfc/include_cleanup has ended today at
>15 UTC.
>
>The majority of voters (52%) voted "Yes" on the primary vote - "Should
>#include directives be cleaned up?" - but the required supermajority
>for a primary vote was not met. Therefore, the primary vote is
>declined.
(snip)
>Interestingly, of all things, the most intrusive vote ("Is it allowed
>to split a large header to reduce dependencies?") got accepted by a
>supermajority. I'll assemble a PR with just the header splitting
>commits and submit it for merging.
Secondary votes are irrelevant if the primary one doesn't pass.
cheers
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
