Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:76093 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 35585 invoked from network); 25 Jul 2014 07:51:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Jul 2014 07:51:53 -0000 Authentication-Results: pb1.pair.com smtp.mail=zeev@zend.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=zeev@zend.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.176 as permitted sender) X-PHP-List-Original-Sender: zeev@zend.com X-Host-Fingerprint: 209.85.220.176 mail-vc0-f176.google.com Received: from [209.85.220.176] ([209.85.220.176:53633] helo=mail-vc0-f176.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F9/76-29475-89C02D35 for ; Fri, 25 Jul 2014 03:51:52 -0400 Received: by mail-vc0-f176.google.com with SMTP id id10so6771998vcb.7 for ; Fri, 25 Jul 2014 00:51:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XL4ERyMK8D5OGgcdeGm/IF2/U5vBuGvGQqH6NGZrfho=; b=D1tBqLRPVdjBWCknFsdZ+mYMSqjTVAeQ3vROCvsRpU8d7vYhPfDac748XiYG3o58ay pVr8tB2E7Pt8tJHAgmuz05BgONIC05dNGKmF0mDwVimhSWiNYVxsWFNgV4GnzbWS4Wht dGcLZNziT7PYApHcyotPmm7plPKPVYHqkuPSIpGvH0H8jsyky46J8Xuvt/CW/l4gQPLO wb9euXgWdTevG9dkax51Fk+4aEDLA9HN3/f489dkqD+8lQoY+gtCyfzbKB8l1dcAHxSN AqLW4HivN+/MSxaqmwNKPaMJn3dd7klt9zf+XC966T1W5fnpwTKMCVG9GPMF3H+Paj2J KP2Q== X-Gm-Message-State: ALoCoQk73iHYAWBRA4Na6dpRg+ju9uagX1UsZKEe0exEiHt2TV1CRTPmqoDfhQiE5GNLagiJiWIoU7nk2MEcL61VzMtgMzrVzG3/dbKrHbWdSziGEEwtjs6xJ4gwhjIMggWo3JoBhidY MIME-Version: 1.0 X-Received: by 10.220.46.5 with SMTP id h5mr102362vcf.55.1406274715294; Fri, 25 Jul 2014 00:51:55 -0700 (PDT) Received: by 10.220.5.136 with HTTP; Fri, 25 Jul 2014 00:51:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 25 Jul 2014 10:51:54 +0300 Message-ID: To: Kris Craig Cc: Yasuo Ohgaki , PHP internals Content-Type: multipart/alternative; boundary=001a11c2d2bedcb51f04feffd8e1 Subject: Re: [PHP-DEV] RFC: Move phpng to master From: zeev@zend.com (Zeev Suraski) --001a11c2d2bedcb51f04feffd8e1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 positi= ve > =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 t= o > 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 wh= at > 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*. 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) - but replacing the implementation with a compatible one absolutely does *not* fa= ll within the realm of "features that affect the language". 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. 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 simpl= y > 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. Zeev --001a11c2d2bedcb51f04feffd8e1--