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
