On Fri, Jul 25, 2014 at 12:51 AM, Zeev Suraski wrote: On Fri, Jul 25, 2014 at 7:28 AM, Kris Craig wrote:
While this is a major change to the language implementation, it does
not actually affect end users in any meaningful way except for the positive
‘side effect’ of their apps running faster. So while we believe that
technically a 50%+1 vote should suffice, we hope to get well over 2/3.
If you're not going to delay this, then you should at very least clarify
the wording in this section. You believe 50%+1 should suffice but hope to
get well over 2/3. So is the *required* majority 50%+1 or 2/3?
The text I put there is exactly what I think about the subject of required
majority. 50%+1 is enough for a change that does not effect end users in
any meaningful way, but I'll be happier if it received a 2/3 majority to
leave any doubts away.
I should also point out that, according to the Voting RFC, whether or not
an RFC "actually affects end users in any meaningful way" is NOT a factor
in determining whether a 2/3 supermajority is required or not. Here's what
it actually states:
For these reasons, a feature affecting the language itself (new syntax
for example) will be considered as 'accepted' if it wins a 2/3 of the
votes. Other RFCs require 50% + 1 votes to get 'accepted'.
Since the phpng RFC already acknowledges that it affects the language
itself, this is clearly a 2/3 requirement situation. Whether it affects
end-users or not is irrelevant. Under current rules, your RFC must have
2/3 support in order to pass.
As the person who wrote that text in the Voting RFC, I can tell you with
absolute certainty that you are 100% wrong in your interpretation, as I've
said numerous times in the past.
A feature that affects the *language* itself is not a feature that
affects the *language implementation*.
That may be what you meant, Zeev, but that's not what you wrote. As Jonny
already pointed out, what you intended isn't relevant if it doesn't match
the final wording you actually put in there.
The Voting RFC doesn't say "language implementation". It says "language".
That means, if it affects the language, it requires 2/3. Period. If you
wanted it to have a more narrow definition, then why didn't you put it in
there? It's just not making any sense to me. You might want to consider
putting an amendment to the Voting RFC to a vote to clarify that language,
but as it stands right now, any feature that affects the language itself--
regardless of userland impact-- requires a 2/3 vote. Saying, "Well, that's
not exactly what I meant," after the fact just isn't a convincing argument
Generally speaking, now that we have a Specification project, the spirit
of the Voting RFC is that changes to the Language Specification would
require 2/3 majority, while all other changes would not. This is also not
100% accurate since there are some elements of the language behavior that
aren't covered by the spec (e.g.superglobal availability and behavior) -
Again, I'd strongly suggest you propose new language for the Voting RFC to
reflect these statements, because none of that is apparent in the current
but replacing the implementation with a compatible one absolutely does
*not* fall within the realm of "features that affect the language".
I disagree. Whether or not the new stuff is "compatible", it does directly
affect the language. The PHPNG RFC itself even acknowledges that it
affects the language. Furthermore, as far as the "spirit" of the Voting
RFC is concerned, I seriously doubt it would be in the spirit of it to
merge a massive overhaul of the codebase that will affect virtually all
development with just a simple majority. It could be (and has been) argued
that this will inevitably lead to userland changes. But again, whether it
affects userland or not is completely irrelevant. The Voting RFC says--
whether you "meant" it to or not, it does say-- that 2/3 is required if it
affects the language, period. It does not contain any exceptions for
lessened impact on userland.
If you recall the 64-bit discussion several months ago, when I was (back
then) on the opposing side, I clearly said to people who said this requires
a 2/3 majority that it's very debatable - because while it does have some
end user impact that changes the language behavior, it's mostly an
implementation issue, which as such requires a simple majority. So I'm
both consistent, and not reinterpreting the rules to fit my needs.
Fair enough. You have been consistent on this so I don't think anyone can
reasonably accuse you of just trying to twist this to suit your needs.
As such, I ask that you at least update the wording to make it clear that
2/3 *is* required for the RFC to pass in order to avoid confusion when it
comes to a vote. I still think you should hold-off until these other
issues of dispute are resolved, though. But that's your choice. I simply
ask that you fix the required majority section to make it in compliance
with current voting rules.
I updated the section to be fully technical and removed my wish of heart
to get a 2/3 majority. Although I'd still very much like to get > 2/3,
it's not required.
According to the current Voting RFC rules, this RFC must require a 2/3
majority because it affects the language. Ugh this is exactly why an
adjudication process is needed, which we don't have that I'm aware of. We
don't have a "supreme court" to decide this. But it's clear that we need
some way to adjudicate this in a manner that would be acceptable to both
sides. The alternative is for you and everyone else to keep repeating
their arguments back and forth. Then, if your RFC gets a simple majority
but not 2/3, we can watch as you try to carry out the merge and Pierre and
whoever else try to block and revert it. I don't think that's an ideal
outcome but that is where we're headed. Even if you believe you're
justified in using this interpretation that expands the stated meaning, I
really think you should go with the 2/3 vote in order to avoid sparking
what could be a very ugly conflict.
Please take the high road on this, then later we can revisit the Voting RFC
and discuss collectively how to make it clearer for situations like this.