Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84880
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.212.174 as permitted sender)
References: <BLU436-SMTP63B4758D2D902644C6BB24E2050@phx.gbl>
	<d29a6faab8dd07ce62f6df153c400b03@mail.gmail.com>	<CALwr1GnMyQrJno24k+hC5WobE29VsQJqcirBYm5XucjW2dxWQA@mail.gmail.com>
	<6e268626bc6b84a3886f39442c827bb6@mail.gmail.com> <CAAyV7nEOpN74zNbc9maU9z-LUcOGN4xyAYi2_EGvv04brezdkQ@mail.gmail.com>
In-Reply-To: <CAAyV7nEOpN74zNbc9maU9z-LUcOGN4xyAYi2_EGvv04brezdkQ@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQKV59C6R/g00R7Uu5aQCj/uhXIapAFVjcT/AZ4zTjMDUyhKxQLGYVwYm0puSGA=
Date: Sun, 15 Mar 2015 21:21:46 +0200
Message-ID: <bc4d2110a723924349c67ccb8d6f8990@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
> Sent: Sunday, March 15, 2015 9:11 PM
> To: Zeev Suraski
> Cc: P=C3=A1draic Brady; PHP Internals
> Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
>
> Zeev,
>
> On Sun, Mar 15, 2015 at 3:07 PM, Zeev Suraski <zeev@zend.com> wrote:
> >> -----Original Message-----
> >> From: P=C3=A1draic Brady [mailto:padraic.brady@gmail.com]
> >> Sent: Sunday, March 15, 2015 9:00 PM
> >> To: Zeev Suraski
> >> Cc: Bob Weinand; PHP Internals
> >> Subject: Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types
> >>
> >> On 15 March 2015 at 16:55, Zeev Suraski <zeev@zend.com> wrote:
> >> > Bob,
> >> >
> >> > Thanks for the update.  This time, though, although I completely
> >> > respect your decision not to put your RFC into a vote unless the
> >> > Dual STH mode fails, I'd like to either (with your permission) take
> >> > over the RFC or propose my own copy and move it to voting as soon
> >> > as allowed.  This, under a commitment that if I see that Basic STH
> >> > is failing to garner a clear majority, I'll retract it and move to
> >> > support the Dual STH RFC instead for the sake of unity.
> >>
> >> No one individual has the right to break the existing rules around
> >> voting.
> >> There has been more than sufficient time to date to rewrite the
> >> voting rules, debate voting rights, extend PHP7's deadline, or
> >> propose the basic RFC so described. A vote in contravention of the
> >> voting rules at the last possible minute cannot, by definition, be
> >> recognised at this time. I wouldn't even vote since it might lend it
> >> an air of ill deserved legitimacy, forgetting for a moment whether a
> >> few PEAR contributions make me any more deserving of a vote than
> >> others.
> >
> > No rule is being broken.
> >
> > The PHP 7 timeline RFC (wiki.php.net/rfc/php7timeline) states the
> following:
> > Line up any remaining RFCs that target PHP 7.0.   |     Now - Mar 15 (4=
+
> > additional months)
> >
> > As Bob pointed out, what 'Line up' means - whether it means vote ends,
> > vote begins, or discussion begins - is completely open to
> > interpretation.  I don't remember what I meant when I wrote it, but
> > arguably, 'line up' is a lot closer to 'start discussing' than 'finish
> > voting', and as is typically the case when something is unclear, the
> > most lax interpretation is acceptable.
>
> By your own words: http://marc.info/?l=3Dphp-
> internals&m=3D142451267910615&w=3D2
>
> > Following Adam's analysis of the timeline, taking the more 'strict' (no
> > pun
> intended!) interpretation of the timeline RFC, we still have until
> tomorrow to
> start the discussion and still target it for 7.0, no?  Given the
> importance of
> this topic, I'd go for the more lax interpretation that allows for votes
> to
> begin by March 15, giving us all a bit more time to discuss.
>
> **votes to begin by March 15**. That was the interpretation you used a
> month ago.

Anthony,

I did not read my own words and therefore didn't notice an even more lax
interpretation was possible.  What you can see is that I always lean toward=
s
the lax interpretation, by my own words.  The fact that this wasn't even
brought as an option was an oversight, but doesn't change the fact that the
timeline RFC doesn't mention anything about voting, but about lining up
RFCs.  Again, I don't pretend to remember what I meant when I wrote it - bu=
t
I would say that if I intended for it to be related to voting - whether it'=
s
voting begins or voting ends - I would have likely wrote that explicitly in
the RFC, instead of using the lax 'line up' term.

If anybody is being political, it's people who try to use the timeline RFC =
-
designed to get PHP 7 out the door as soon as possible - while in parallel
denying a competing RFC to go to a vote on technicalities ("it's not the
same RFC"), to be discussed at all due to other technicalities ("you missed
the deadline!"), and at the same time suggest that there are "voting
irregularities", incidentally, among the people voting against their RFC.
Anthony, in case you don't know, *that* is politics.  Not putting an RFC to
a vote.

Zeev