On Fri, Jul 25, 2014 at 12:51 AM, Zeev Suraski <z...@zend.com> wrote:
> > > > On Fri, Jul 25, 2014 at 7:28 AM, Kris Craig <kris.cr...@gmail.com> 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 for me. > 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 wording. > 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. --Kris
