Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84826 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 87112 invoked from network); 15 Mar 2015 14:15:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Mar 2015 14:15:42 -0000 Authentication-Results: pb1.pair.com header.from=bobwei9@hotmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=bobwei9@hotmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.99 as permitted sender) X-PHP-List-Original-Sender: bobwei9@hotmail.com X-Host-Fingerprint: 65.55.111.99 blu004-omc2s24.hotmail.com Received: from [65.55.111.99] ([65.55.111.99:58984] helo=BLU004-OMC2S24.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 87/69-29489-D0495055 for ; Sun, 15 Mar 2015 09:15:41 -0500 Received: from BLU437-SMTP72 ([65.55.111.71]) by BLU004-OMC2S24.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sun, 15 Mar 2015 07:14:56 -0700 X-TMN: [Ql+XV2yEKHF9xUOi23tysuOeKgGNfcJU] X-Originating-Email: [bobwei9@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) In-Reply-To: Date: Sun, 15 Mar 2015 15:14:51 +0100 CC: PHP Internals List Content-Transfer-Encoding: quoted-printable 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> To: Zeev Suraski X-Mailer: Apple Mail (2.2070.6) X-OriginalArrivalTime: 15 Mar 2015 14:14:54.0191 (UTC) FILETIME=[6899A7F0:01D05F2A] Subject: Re: [PHP-DEV] [RFC] Basic Scalar Types From: bobwei9@hotmail.com (Bob Weinand) > Am 14.03.2015 um 00:44 schrieb Zeev Suraski : >=20 >> Zeev, >>=20 >> 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. >=20 > Bob, >=20 > 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. >=20 > But again, I respect your position. Maybe that was the intention. But if you want that, we'd first need to = allow that explicitly in the RFC. If we just all act like "that rule doesn't fit my current situation, = let's ignore it" =E2=80=A6 why do we then have rules at all? I'd like to consider them as hard rules which we don't break, except a = RM requires it. >> 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Thoughts? >=20 > Zeev After having thought a lot about it, I'll announce my intentions shortly = in a separate thread and clarify the way this RFC will go. Bob=