Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75737
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.177 as permitted sender)
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>
In-Reply-To: <CAKOpQSxhHc+maUKj-4jUw6_TQNgDW4uK2XYSEvz9f_Ks2f60Lw@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQJLEP/c3uJc+QUSn+XVIg2W/Ho8NgMQcjoQAfVy1fUBnE4eEgFgwf25Akotm2qaYL8IkA==
Date: Mon, 21 Jul 2014 08:56:30 +0300
Message-ID: <2d914cfcd940ecd5e90f5ced33967752@mail.gmail.com>
To: Kris Craig <kris.craig@gmail.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=20cf307ca2c2de922c04feadc420
Subject: RE: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP
From: zeev@zend.com (Zeev Suraski)

--20cf307ca2c2de922c04feadc420
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

See below in blue:



I feel compelled to voice just how extremely inappropriate it seems to me
to delete the other side's argument on an RFC without any consultation.
 What I proposed was that Zeev and maintain the 7 argument and Andrea
maintain the 6 argument.  This effectively smells like blatant tampering to
me.  If Zeev says it was accidental, I'd be willing the to give him the
benefit of the doubt and let that be the end of it, though it still
troubles me that this happened.  Hopefully, it will never happen again.



The removed paragraphs were added in this context =E2=80=93 a note from And=
rea to
me:



> Third, numerous people (myself included) actively proposed we skip

> version

> 6 and go with version 7;  Dismissing that with "I don't think the

> alternative naming options are really much better" doesn't seem to

> belong in an RFC.  The merits of this option - which were really more

> about the drawbacks of calling it '6' and the lack of drawbacks of
calling it '7'

> should be properly described in the RFC.



I=E2=80=99ve covered the PHP 7 issue more now.



The removed paragraphs were actually the RFC=E2=80=99s =E2=80=98case for PH=
P 7=E2=80=99.  As the
champion for the PHP 7 case, I was 100.0% entitled to remove it as I
thought it wasn=E2=80=99t doing a good job at presenting that case, and rep=
lace it
with some real pro-7 content.



Moreover, after my edits, I proposed to Andrea that we take more time for
discussion, make sure each =E2=80=98camp=E2=80=99 is good with the post-edi=
ts RFC (as they
were substantial), and then restart the vote.  Andrea initially didn=E2=80=
=99t feel
it was necessary and wanted to simply extend the vote, which I was OK
with.  At this time I assumed she read the updated RFC but perhaps she
hasn=E2=80=99t.   Note that even after she restored the edits, she didn=E2=
=80=99t feel the
RFC was suitable for vote as she no longer felt the PHP 6 case was being
properly represented, with our without the old =E2=80=98case for PHP 7=E2=
=80=99 paragraphs.



That said, I agree 100% that the vote should have been cancelled.  Whether
it was accidental or not, Zeev's unilateral gutting of the pro-6 argument
contaminated the whole process and rendered any subsequent vote results
unreliable.  The only sensible and fair recourse at that point was to clear
all votes, fix the RFC, then start the vote process over.  She didn't do it
because she didn't like the results.  She did it because the RFC had been
tampered with in such a manner as to likely influence the voting.



It was not accidental and I said so almost immediately after Andrea sent
the note to the list about the paragraphs being removed.



Now, if you move away from your biased point of view, perhaps you=E2=80=99d=
 notice
some issues elsewhere too:

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.

2.       When I asked the vote to be canceled, it was rejected =E2=80=93 ev=
en
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 paragr=
aphs
into a real case for 7 =E2=80=93 why was it suddenly appropriate to cancel =
the vote
immediately?  How is it different from the situation on the ground when the
RFC went for a vote with a one sided 6 position?

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 fee=
l they
were doing a good job representing the case for 6.



On my side, I don=E2=80=99t feel I did **anything** wrong.  I edited paragr=
aphs
that were supposed to be in my jurisdiction, at least according to the
person who wrote them;  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, last but absolutely not
least, I=E2=80=99m fine with Andrea canceling 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.



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 vote
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) once
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 Andrea
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 repr=
esented
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 RFC
is balanced and represents 7 well;  Needless to say, that person voted for
6.

Now let=E2=80=99s focus on bringing this to revote and being done with it. =
 And
getting the kids to kindergarten J



Zeev

--20cf307ca2c2de922c04feadc420--