Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76162
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPgLKiiWCqFcZyzOAH-OaUWtwhXVi0ZicNW_2PbThbnTd6RKAA@mail.gmail.com>
References: <b39ebab3d19d76cda9bafa25919c0e67@mail.gmail.com>
	<CAGa2bXaRgqKWG_M3n+H+=6FYqzNVE3hi3VfO8Ji1Ckf9uV+PVQ@mail.gmail.com>
	<CAKOpQSxkO4xaZP=rsTwdzX6vD9b2qAkqaXCi2CC63sWPrv0J5A@mail.gmail.com>
	<CAPgLKiiWCqFcZyzOAH-OaUWtwhXVi0ZicNW_2PbThbnTd6RKAA@mail.gmail.com>
Date: Sat, 26 Jul 2014 14:41:50 -0700
Message-ID: <CAKOpQSy23uvHaEKoToumHkewO9Adve-zPv_c-vFwn6xUcJ9u5A@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e011847a2c218f604ff1f8ef3
Subject: Re: [PHP-DEV] RFC: Move phpng to master
From: kris.craig@gmail.com (Kris Craig)

--089e011847a2c218f604ff1f8ef3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 25, 2014 at 12:51 AM, Zeev Suraski <zeev@zend.com> wrote:

>
>
>
> On Fri, Jul 25, 2014 at 7:28 AM, Kris Craig <kris.craig@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 posit=
ive
>> =E2=80=98side effect=E2=80=99 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 require=
d
> 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 facto=
r
>> in determining whether a 2/3 supermajority is required or not.  Here's w=
hat
>> 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'v=
e
> 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 no=
t
> 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 requir=
es
> 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 tha=
t
>> 2/3 *is* required for the RFC to pass in order to avoid confusion when i=
t
>> 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 simp=
ly
>> 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

--089e011847a2c218f604ff1f8ef3--