Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84747 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 60935 invoked from network); 13 Mar 2015 23:44:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Mar 2015 23:44:08 -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 74.125.82.170 as permitted sender) X-PHP-List-Original-Sender: zeev@zend.com X-Host-Fingerprint: 74.125.82.170 mail-we0-f170.google.com Received: from [74.125.82.170] ([74.125.82.170:34870] helo=mail-we0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CD/8B-34457-74673055 for ; Fri, 13 Mar 2015 18:44:08 -0500 Received: by webcq43 with SMTP id cq43so2060031web.2 for ; Fri, 13 Mar 2015 16:44:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=1qABrzfM30OGzsb4uj3e/mTkphz4ED923qdPggpswhc=; b=LnvCxeb5BqkPYjv9qYrRouslTQiP3GSMjeoDHCph24xHDXA35zBkAAj29gknc2OanR j545NlF8XO5/tqb1JkfYDKQNhV2/l52ViLF0oyHvvSv7FkqTV5ERIbubgKkDM4g+rqfA 6XGKVa0JlS2VLv+g3U1fLy1Nxr+T/LhL5rbmEZgPMwDjQprAsGZwgBzGrNuW2/bCt06P LTo10Ew7qV/h+Ilis9eazBne/R+X6PsFQ68MJdYpB/epj1H3ljF0zD70FSEGQ+mrTL3X JSA9LowsOAXmjiQ0UWPWf1WcC0xTFJgw2LIONmI9MR455nGhFeLhEjFJjCn/dkgiZ5E6 KxBA== X-Gm-Message-State: ALoCoQnP83LEP11UJQb6AqFufOOoJysT7I1LfbSB145AXk/wFz/oqGksazhiWjaAeXxsblAW6ATuTzooJA/JLEtGqpJMxm/EWnHUhtF0xGA4XGoDuRv8kkuM70KOpiL8rKhaVPcVQNTbI/RYj6A9zVoEifFSpxajoQ== X-Received: by 10.180.39.33 with SMTP id m1mr101990725wik.26.1426290244724; Fri, 13 Mar 2015 16:44:04 -0700 (PDT) References: <325E0097-FD7E-4997-A95D-20C62368E162@zend.com> <55031C54.6060802@eliw.com> <7CE491F0-C243-4788-ADA2-5DA9DF1D1168@php.net> <332304ae552bfc635f999a8d73b505f0@mail.gmail.com> <7de9d64ab85cad86836b43c8acbed439@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLg0UZIsq+15w5AwD0SDZXLD3VPogLMHcQTAaGt238CcCYc0AGWzLp/ApGYoQUDQRlseQIrE/I/AkSeeDQDMwLjegK3zgrBAiTpF5iaI/C1EA== Date: Sat, 14 Mar 2015 01:44:04 +0200 Message-ID: To: Bob Weinand Cc: PHP Internals List Content-Type: text/plain; charset=UTF-8 Subject: RE: [PHP-DEV] [RFC] Basic Scalar Types From: zeev@zend.com (Zeev Suraski) > Zeev, > > If I put it into vote until Sunday, we're breaking the voting process. Which > required an apt discussion phase which definitely isn't given when we start > Sunday. Bob, I do see it differently but obviously very much respect your position. Why do I see it differently? The mandatory two week discussion period is there to avoid a situation where there's not enough time to debate the merit of the proposal, as well as to avoid 'stealth' RFCs where it's over before some people even notice. Both of these elements aren't here. An identical proposal has been debated in depth and from all possible directions? Check. It's perhaps the most watched internals@ topic of all times with zero chance for stealth RFCs? Check. There's not going to be any new meaningful discussion over the next 10 days where something that hasn't already been said will be said. But again, I respect your position. > Also. Your timeline RFC leaves a bit room for interpretation ("Line up" > means? Put into discussion? Vote? Have votes all already accepted?) . If > necessary, I'll rather push timeline a bit than breaking vote process. Good point. Looks like I shouldn't be writing non-technical RFCs as they're always more than a bit open for interpretation :) Or at least internals@ needs to scrutinize them more. Either way, you're right that technically we could say your RFC is very much 'lined up' right now, before the Mar 15 deadline. While I'd hate to prolong the timeline for a technicality like that, for this specific case I think it's worth it - it's an extremely important topic and we've been dealing with it for almost a decade. Also, the good news is that it's unlikely to delay the 2nd milestone given that we have implementations for all of the different options already. Now, my key concern is that you're saying you'd put it to a vote only if you see both other RFCs are failing. The Dual Mode RFC is hovering above and below passing, and we have no way of knowing how many people who voted in favor of the Dual Mode RFC would actually much rather vote for the Basic one if it was available (we know of at least one, and actually two if you count me - my guess is there are a lot more). What I think makes sense is to do something similar to what I did & plan to do with the Coercive STH RFC - put it up to a vote as soon as practical; If we see that it's not passing, withdraw it. I'm very clearly on the record saying that if the Dual Mode RFC remains the only viable alternative (besides not having anything) - I'll not only change my vote to yes, but also encourage everyone else that I can to do the same (which I do think could swing at least some votes). If Anthony's right and there's no chance it'll pass - no harm done, except for maybe we've lost a couple of weeks. Thoughts? Zeev