Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76098
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.43 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: Fri, 25 Jul 2014 10:27:41 +0200
Message-ID: <CAH-PCH4uHf9EwdM5OpU3OGJqThFncOSeTL+FhfwoL1Ak8myV7Q@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, Kris Craig <kris.craig@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2e0a8c6de0204ff0058ee
Subject: Re: [PHP-DEV] RFC: Move phpng to master
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a11c2e0a8c6de0204ff0058ee
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2014.07.25. 9:52, "Zeev Suraski" <zeev@zend.com> ezt =C3=ADrta:
>
> 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
positive
> > =E2=80=98side effect=E2=80=99 of their apps running faster.  So while w=
e 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 clarif=
y
> > 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
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 synta=
x
> > 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 affect=
s
> > end-users or not is irrelevant.  Under current rules, your RFC must hav=
e
> > 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 affect=
s
> the *language implementation*.

hi,

I'm not really following the phpng development that closely, but afaik it
does have some userland impact (the change for using the same argument name
in a function signature multiple times and the change in func_get_args()
comes into mind).

We also discussed before that major breakage in the extension "api" would
also warrant a 2/3 vote, but it seems that you disagree with that.

My last argument is, that given that we allow anybody with a php.net
account to vote on Zend Engine changes, we are always safer with the 2/3
vote.
That way the worst thing that can happen is something not getting into, but
the authors can try again (after fixing the cause of the no votes), but
with simple majority it would be rather easy to force something into the
language, even if all of the active Zend maintainers vote no because it is
a horrible design decision or has a crappy implementation.

just my 2 cents ofc.

--001a11c2e0a8c6de0204ff0058ee--