Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:90623 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 57376 invoked from network); 13 Jan 2016 17:26:56 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Jan 2016 17:26:56 -0000 Authentication-Results: pb1.pair.com header.from=me@rouvenwessling.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=me@rouvenwessling.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain rouvenwessling.de from 80.241.60.215 cause and error) X-PHP-List-Original-Sender: me@rouvenwessling.de X-Host-Fingerprint: 80.241.60.215 mx2.mailbox.org Received: from [80.241.60.215] ([80.241.60.215:51682] helo=mx2.mailbox.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 09/74-34116-ED886965 for ; Wed, 13 Jan 2016 12:26:55 -0500 Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id A25DF4208D; Wed, 13 Jan 2016 18:26:51 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173]) (amavisd-new, port 10030) with ESMTP id ahAkwdyJSyzk; Wed, 13 Jan 2016 18:26:50 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) In-Reply-To: Date: Wed, 13 Jan 2016 18:26:49 +0100 Cc: Joe Watkins , Zeev Suraski , Bob Weinand , PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: <1E7F9387-A836-46AC-BA62-E4141DDBB387@rouvenwessling.de> References: <373698cabe053cb9bec8e1f6dc969906@mail.gmail.com> To: Ferenc Kovacs X-Mailer: Apple Mail (2.3096.5) Subject: Re: [PHP-DEV] [RFC] [VOTE] PHP 5's Support Timeline From: me@rouvenwessling.de (=?utf-8?Q?Rouven_We=C3=9Fling?=) > On 13 Jan 2016, at 16:23, Ferenc Kovacs wrote: >=20 > I don't think we can avoid some confusion, we could have had a three = way > vote here (keep the current, expand #1, expand #2) but then people = would > argue that the tho expand options should win in sum or one of those > separately. We could have delayed the second vote after the first one, = but > then it could be argued that somebody would have voted differently if = they > knew the options for the second vote (or even the progress of the = votes) > beforehand. Or Zeev could have picked one of the two dates, and seeing = the > results it is entirely possible that the vote would have failed = regardless > of the date picked (assuming that the No voters would have voted no > anyways, and some of the yes voters would have voted no because of = their > disagreement with the proposed date) which seems to be a bad outcome = seeing > how the yes-no vote went to 42:2. > So I don't think we had a objectively better alternative or how could > always have the best outcome with a simple vote of two options. I don=E2=80=99t have voting rights but I don=E2=80=99t think there is a = problem with multiple votes in one RFC, even if they are chained (b only matters if a passes). What doesn't make = sense is for the voting right to be restricted based on how one voted (may only vote in b if = voted for a with option X).=20 Of course most people would make the most restrictive choice in the = second vote if they were against the whole RFC, but that would make it an effective reflection on = how everyone feel. Best regards Rouven