Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94331 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 21818 invoked from network); 30 Jun 2016 05:28:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 Jun 2016 05:28:15 -0000 Authentication-Results: pb1.pair.com header.from=aaron@trowski.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=aaron@trowski.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain trowski.com designates 199.38.81.6 as permitted sender) X-PHP-List-Original-Sender: aaron@trowski.com X-Host-Fingerprint: 199.38.81.6 mercury.negativeion.net Received: from [199.38.81.6] ([199.38.81.6:57416] helo=mercury.negativeion.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CE/60-14264-EEDA4775 for ; Thu, 30 Jun 2016 01:28:14 -0400 Received: from localhost (localhost [127.0.0.1]) by mercury.negativeion.net (Postfix) with ESMTP id B81C83B8EDF7 for ; Thu, 30 Jun 2016 01:28:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at negativeion.net Received: from mercury.negativeion.net ([127.0.0.1]) by localhost (mercury.negativeion.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dBghZ4v962G for ; Thu, 30 Jun 2016 01:28:11 -0400 (EDT) Received: from [10.0.1.3] (unknown [173.225.150.231]) by mercury.negativeion.net (Postfix) with ESMTPSA id 1405A3B8EDEA for ; Thu, 30 Jun 2016 01:28:11 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) In-Reply-To: Date: Thu, 30 Jun 2016 00:28:11 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <6D1403D4-07D7-43C2-BF21-37C2FA13B604@trowski.com> References: To: PHP internals X-Mailer: Apple Mail (2.3124) Subject: Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions From: aaron@trowski.com (Aaron Piotrowski) Hi Dan, > On Jun 29, 2016, at 3:41 PM, Dan Ackroyd = wrote: >=20 > For the record, I'm beginning to think the RFC process should probably > be slightly more orchestrated, and RFCs should have a "pre-vote" > announcement at least one week before the vote actually opens, when > the RFC author thinks the discussion of the RFC is complete. >=20 > This point would be the time for the implementations full impact on > the PHP engine to be analyzed, and also when the final voting choice > can be discussed/challenged before the voting is actually open. >=20 Sorry if this RFC was a little rushed. I originally hoped to make these = changes for 7, then the original PR got pushed off to 7.1 and forgotten = about until it was almost too late even for 7.1. I agree that a pre-vote phase could be useful, as it may help bring more = attention to an RFC before voting actually opens. There seems to be a = pattern of issues with RFCs not being discussed until voting has begun. = The pre-vote phase could replace one week of the discussion period, so = an RFC would still only need a minimum of two weeks between announcement = and voting. Cheers! Aaron Piotrowski=