Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74273 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 3630 invoked from network); 17 May 2014 11:35:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 May 2014 11:35:59 -0000 Authentication-Results: pb1.pair.com smtp.mail=anatol.php@belski.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=anatol.php@belski.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error) X-PHP-List-Original-Sender: anatol.php@belski.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:54235] helo=klapt.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FB/E6-35141-B9947735 for ; Sat, 17 May 2014 07:35:56 -0400 Received: by klapt.com (Postfix, from userid 33) id B3AA423D6106; Sat, 17 May 2014 13:35:52 +0200 (CEST) Received: from 178.2.22.225 (SquirrelMail authenticated user anatol@belski.net) by webmail.klapt.com with HTTP; Sat, 17 May 2014 13:35:52 +0200 Message-ID: In-Reply-To: <-4728021288282848432@unknownmsgid> References: <3939936079205827190@unknownmsgid> <2602f5303ca0c63345ec2d234ab24003.squirrel@webmail.klapt.com> <-4728021288282848432@unknownmsgid> Date: Sat, 17 May 2014 13:35:52 +0200 To: "Zeev Suraski" Cc: "Anatol Belski" , "PHP internals" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] A call for help (urgent) From: anatol.php@belski.net ("Anatol Belski") On Sat, May 17, 2014 13:13, Zeev Suraski wrote: > No, you're watching the Voting RFC going haywire. > > > It's the second time we have an RFC that deals with internal > implementation as opposed to features and functions, something the RFC > process was never designed to do. And it appears to be failing, much like > it almost failed the last time around. > > Last time it happened I raised the hope that non-engine contributors > will refrain from placing votes on such RFCs, we may need to (try and) > formalize it. > > Zeev > > > >> On 17 במאי 2014, at 14:02, Anatol Belski wrote: >> >> >>> On Sat, May 17, 2014 12:53, Zeev Suraski wrote: >>> All, >>> >>> >>> >>> In case there's any chance people lost track in the noise: >>> >>> >>> >>> Please, please - vote No on >>> https://wiki.php.net/rfc/size_t_and_int64_next#vote >>> >>> >>> >>> We're in an unprecedented situation where almost all of the code >>> contributors to the engine are against a patch that is being forced on >>> them for no reason, negates months of hard work performed to get us >>> phpng, and is somehow enjoying a majority (almost exclusively from >>> people who are not engine contributors). >>> >>> I urge everyone with a right to vote (and only those, as per >>> https://wiki.php.net/rfc/voting) to vote no, and even those who voted >>> yes to revert their votes to no. >>> >>> We need your help! >>> >> Am i watching a CNN movie? >> >> >> Cheers >> >> >> Anatol >> >> Exactly, the single thing I see failing here is the voting RFC. Not because of itself, but because it's useless when it comes to the politics we have here. And that confrontations do actually much more harm than any technical issue ever. Regards Anatol