Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75742
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <2d914cfcd940ecd5e90f5ced33967752@mail.gmail.com>
References: <84603C6F-F984-4F73-892A-4416391E4769@ajf.me>
	<FF53F427-6E40-439F-ADCC-A1AD0E808CA4@ajf.me>
	<alpine.DEB.2.10.1407202212360.4247@whisky.home.derickrethans.nl>
	<CAF+90c_bswMjh5J_mJ2Jj3b2WDr5eYWcEAa7s-nrjrqkDsyW4A@mail.gmail.com>
	<-4203495342985824219@unknownmsgid>
	<CAKOpQSxhHc+maUKj-4jUw6_TQNgDW4uK2XYSEvz9f_Ks2f60Lw@mail.gmail.com>
	<2d914cfcd940ecd5e90f5ced33967752@mail.gmail.com>
Date: Mon, 21 Jul 2014 00:41:03 -0700
Message-ID: <CAKOpQSyJXqBDHBTD_vLjTW2aaEpRx8W53XwYzzwSx7FVoPTE3A@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, Derick Rethans <derick@php.net>, Andrea Faulds <ajf@ajf.me>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e011847a2a200d704feaf3a7b
Subject: Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP
From: kris.craig@gmail.com (Kris Craig)

--089e011847a2a200d704feaf3a7b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

See below in red.


> It was not accidental and I said so almost immediately after Andrea sent
> the note to the list about the paragraphs being removed.
>

I didn't see that, my bad.  The point I was trying to make is that,
whatever the explanation, I think you should be given the benefit of the
doubt as far as your intentions were concerned.


> Now, if you move away from your biased point of view, perhaps you=E2=80=
=99d notice
> some issues elsewhere too:
>

I am biased in favor of PHP 6, just as you're biased in favor of PHP 7.
 However, I've done my best to be fair without allowing that bias to affect
that.  That's why, for example, I urged Andrea to give you access to the
RFC so you could expand the section in favor of PHP 7.  It's also why I
urged her to grant the delay you requested.  Please believe me, I would
have been just as troubled if Andrea or someone else had gutted the section
in support of your argument.

> 1.       The vote started with no real case for PHP 7 in there.  I made
> it clear in past weeks I intended to write one, and said it would take
> time.  The supposed =E2=80=98case for PHP 7=E2=80=99 that was added there=
 by PHP 6
> proponents, is now turning out to be a further case for PHP 6.
>
Agreed.  You should have been the one to write that section.  Ultimately,
you were.  I haven't been following this very closely (though I am now).
 If I'd known when it came to a vote that you still hadn't had a chance to
write your section, I would have asked that the vote be cancelled to give
you more time.

> 2.       When I asked the vote to be canceled, it was rejected =E2=80=93 =
even
> though 20 people voted on a 100.0% one sided RFC before I put in a real
> case for 7.  Let=E2=80=99s say it was wrong for me to edit these two para=
graphs
> into a real case for 7 =E2=80=93 why was it suddenly appropriate to cance=
l the vote
> immediately?  How is it different from the situation on the ground when t=
he
> RFC went for a vote with a one sided 6 position?
>
You're right that the vote should've been cancelled-- or, more to the
point, it never should've been initiated in the first place.  I still don't
like how you gutted the 6 paragraph.  However, I'm also not happy that the
vote was called before you'd had a chance to finish your section of the
RFC.  I don't think that either one justifies the other.  They were both
mistakes that we should learn from.

And again, if I'd been paying closer attention and realized you hadn't
completed your section yet, I would've been just as critical of Andrea for
starting the vote before the RFC was ready.  I can understand her eagerness
to settle this issue and we certainly wouldn't want to have the vote
delayed for months over this, but there was no need for it to be rushed
like this.  I don't think there would've been any harm in giving you an
extra few weeks to get your section written, especially considering what
you're dealing with over there right now with those missiles.

> 3.       Fact it that when the vote was canceled, it was 25/15 in favor
> of 7 and with 7 gaining rapidly (it was 7 to 13 ~12hrs earlier).  Another
> fact is that even once these paragraphs were restored, Andrea didn=E2=80=
=99t feel
> they were doing a good job representing the case for 6.
>
The entire vote was tainted.  It was first tainted by your section not
being completed and further tainted by Andrea's section being gutted.  At
that point, I don't care what the results were; it had to be cancelled.


> On my side, I don=E2=80=99t feel I did **anything** wrong.
>

I think you did, though it's now clear there's more than enough blame to go
around here.  Andrea shouldn't have rushed the vote and I wasn't paying
close enough attention to realize you hadn't finished your section when the
voting started. We all have our reasons and explanations, but that doesn't
make it right.  It's important to learn from our mistakes in times like
these so that we don't repeat them in the future.

I asked for an extended discussion time which would have immediately turn
> out the missing paragraphs had people thought they were in fact necessary
> for the PHP 6 case;
>

And you should have been given that time.  I agree with you 100% on that.


> And, last but absolutely not least, I=E2=80=99m fine with Andrea cancelin=
g the
> vote, as my goal from the get go (weeks ago) was that the best case would
> be made for 6, the best case would be made for 7, and people will vote
> accordingly.
>

From this moment on, let's agree that anyone who supports PHP 6 should keep
their hands off of the PHP 7 section and anyone who supports PHP 7 should
keep their hands off of the PHP 6 section.  That way, each side will be
responsible for making its best arguments without interference.  When
everyone is satisfied with the draft, *then* the vote can be initiated.  If
you and Andrea could agree to that, I think we'll be able to avoid any
further drama.


>
>
> Given Zeev's current situation, I think we should grant his request for a
> delay in voting, especially since we had to start over, anyway.  There's =
no
> rush and I think it's important that we get this right, given the passion
> there seems to be on both sides of this particular debate.  I would also
> ask that Andrea do one final read-thru of the RFC before putting it to vo=
te
> just to make sure there haven't been any new unexpected edits, and that
> everyone agree not to alter the RFC's contents (namely the arguments) onc=
e
> voting has begun.  That should be a universal rule with RFCs, anyway, I
> think.
>
>
>
> There=E2=80=99s no need to delay on my account, we=E2=80=99re carrying on=
 =E2=80=93 I was just
> extremely busy in the last couple of weeks.  I think that as soon as Andr=
ea
> feels comfortable with the case for PHP 6 we can go to a vote.
>
> I do welcome other ideas for how to improve the case for 7, too.
>
>
>
> If we=E2=80=99re talking about universal rules for RFCs =E2=80=93 a =E2=
=80=98choose between a and
> b=E2=80=99 RFC should never go into a vote with one of the cases clearly
> misrepresented in it.  The ones to judge whether it=E2=80=99s properly re=
presented
> need to be the proponents of each option.  As an anecdote, yesterday
> morning, I got an email from a certain someone telling me he feels the RF=
C
> is balanced and represents 7 well;  Needless to say, that person voted fo=
r
> 6.
>
> Now let=E2=80=99s focus on bringing this to revote and being done with it=
.  And
> getting the kids to kindergarten J
>

I agree.  Each side should write and maintain their own arguments prior to
any vote taking place.


> Zeev
>

--Kris

--089e011847a2a200d704feaf3a7b--