Good evening,
It is finally time to settle this matter once and for all. What shall be the name of the next release of PHP: PHP 6 or PHP 7?
The poll is now open: https://wiki.php.net/rfc/php6#vote
Voting shall end in a week’s time on 2014-07-27.
Thanks!
Andrea Faulds 
http://ajf.me/
Andrea,
Please stop  (pause) this vote.  I told you I want to represent the 
cars for PHP 7, and I told you it'll take a bit of time - and that was 
before my city became under rocket fire..
There's no rush for this RFC - it can easily wait a week or even a few 
more weeks if necessary.
I'll try to invest time in it this week.
Thanks,
Zeev
Good evening,
It is finally time to settle this matter once and for all. What shall be the name of the next release of PHP: PHP 6 or PHP 7?
The poll is now open: https://wiki.php.net/rfc/php6#vote
Voting shall end in a week’s time on 2014-07-27.
Thanks!
Andrea Faulds
http://ajf.me/
I took the time to rewrite the case for PHP 7.  It's a complete rewrite 
written by someone who actually believes that this is the right choice for 
us to pick :)
I'm sure people will have comments and may want to both improve the case 
for 6 and 7 - so I do recommend we give it another extra week of 
discussions to refine the RFC, and then restart the vote.
Zeev
-----Original Message-----
From: Andrea Faulds [mailto:ajf@ajf.me]
Sent: Sunday, July 20, 2014 2:26 AM
To: PHP Internals
Subject: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHPGood evening,
It is finally time to settle this matter once and for all. What shall be
the name
of the next release of PHP: PHP 6 or PHP 7?The poll is now open: https://wiki.php.net/rfc/php6#vote
Voting shall end in a week's time on 2014-07-27.
Thanks!
Andrea Faulds
http://ajf.me/--
To unsubscribe,
visit:
http://www.php.net/unsub.php
I took the time to rewrite the case for PHP 7. It's a complete rewrite
written by someone who actually believes that this is the right choice for
us to pick :)
Great, we actually have a case now!
I'm sure people will have comments and may want to both improve the case
for 6 and 7 - so I do recommend we give it another extra week of
discussions to refine the RFC, and then restart the vote.
I’d rather not put it off much longer, but people can change votes, so I could extend the voting by another week if need’s be.
Andrea Faulds 
http://ajf.me/
I'm sure people will have comments and may want to both improve the
case for 6 and 7 - so I do recommend we give it another extra week of
discussions to refine the RFC, and then restart the vote.I'd rather not put it off much longer, but people can change votes, so I
could
extend the voting by another week if need's be.
Sounds reasonable.
I do recommend to everyone who voted before there were separate 'Case for 
PHP 6' and 'Case for PHP 7' to re-read the RFC one last time to see if it 
changes their mind...
Zeev
I do recommend to everyone who voted before there were separate 'Case for
PHP 6' and 'Case for PHP 7' to re-read the RFC one last time to see if it
changes their mind…
I’d second this and say people should perhaps read older discussions too.
That said, it looks set to be a very close vote. I won’t be surprised if one side wins by just a single vote.
-- 
Andrea Faulds 
http://ajf.me/
I took the time to rewrite the case for PHP 7. It's a complete rewrite
written by someone who actually believes that this is the right choice for
us to pick :)
Is '6' really such an unlucky number? Wasn't Vista essentially Windows 
6? ...
I don't have a vote, but I do have sufficient 'PHP6' material in my 
local archive to understand why using that simply does not work. It 
would be interesting to see the voting choices based on the time the 
voter has been using PHP? Prior to 2010 there was sufficient activity on 
PHP6 for it to have reached a point where it had an existence even 
without a formal release.
-- 
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact 
L.S.Caine Electronic Services - http://lsces.co.uk 
EnquirySolve - http://enquirysolve.com/ 
Model Engineers Digital Workshop - http://medw.co.uk 
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Good evening,
It is finally time to settle this matter once and for all. What shall be
the name of the next release of PHP: PHP 6 or PHP 7?
It might be just me, but the whole RFC actually seems particularly 
one-sided. The argument for PHP 6 is very short and reads half-baked.  The 
overwhelming majority of this very short section of the RFC is spent 
describing how naming the release “PHP 6” will be a problem, with a very 
wishy-washy conclusion that the author “expects” and “thinks” it won’t end 
up being a problem. The PHP 6 section makes no attempt to provide counter 
points to things mentioned in the following section, nor really attempts to 
make any strong point at all.
As for the PHP 7 section, this is by far the dominant part of the RFC. Both 
in terms of physical presence, but also points and counter-points.
It also contains, IMO unnecessarily, light-hearted and jokey comments not 
befitting an RFC  — unless you see the RFC as a joke too ;) — about 6 being 
a failed version in other software, and 7 a lucky number. Seriously?..
The RFC as a whole is very light on trying to summarise, or at least 
provide reference to, the history of "PHP 6” and discussions around it. 
This is disappointing, if the aim was to see a balanced summary of previous 
discussions.  However, this particular gripe is a common issue with our 
RFCs as a whole.
Personally, regardless of the content of the RFC, I feel that the choice is 
obvious. I’m just a little concerned about the lack of quality from both 
“sides” in presenting their argument(s), or not.
The poll is now open: https://wiki.php.net/rfc/php6#vote
Voting shall end in a week’s time on 2014-07-27.
Thanks!
Andrea Faulds
http://ajf.me/
It might be just me, but the whole RFC actually seems particularly
one-sided. The argument for PHP 6 is very short and reads half-baked. The
overwhelming majority of this very short section of the RFC is spent
describing how naming the release “PHP 6” will be a problem, with a very
wishy-washy conclusion that the author “expects” and “thinks” it won’t end
up being a problem. The PHP 6 section makes no attempt to provide counter
points to things mentioned in the following section, nor really attempts to
make any strong point at all.
I swear the PHP 6 section was much longer before. Did Zeev delete some of it?
Andrea Faulds 
http://ajf.me/
It might be just me, but the whole RFC actually seems particularly
one-sided. The argument for PHP 6 is very short and reads half-baked. The
overwhelming majority of this very short section of the RFC is spent
describing how naming the release “PHP 6” will be a problem, with a very
wishy-washy conclusion that the author “expects” and “thinks” it won’t end
up being a problem. The PHP 6 section makes no attempt to provide counter
points to things mentioned in the following section, nor really attempts to
make any strong point at all.I swear the PHP 6 section was much longer before. Did Zeev delete some of it?
Zeev must have as the only person who edited it since was him.
I’ve restored the Rationale section from before to “The Case for PHP 6”.
-- 
Andrea Faulds 
http://ajf.me/
I swear the PHP 6 section was much longer before. Did Zeev delete some of it?
Zeev must have as the only person who edited it since was him.
I’ve restored the Rationale section from before to “The Case for PHP 6”.
Yes it was me - but I remembered these paragraphs actually being added 
as "the case for PHP 7" after our initial discussion a few weeks ago. 
I had a certain someone tell me as recently as this morning that they 
do a great balanced pitch for the case for PHP 7 - which I didn't 
quite agree with :)
Anyway, no problem that they're back...
Zeev
As for the PHP 7 section, this is by far the dominant part of the RFC. Both
in terms of physical presence, but also points and counter-points.It also contains, IMO unnecessarily, light-hearted and jokey comments not
befitting an RFC — unless you see the RFC as a joke too ;) — about 6 being
a failed version in other software, and 7 a lucky number. Seriously?..The RFC as a whole is very light on trying to summarise, or at least
provide reference to, the history of "PHP 6” and discussions around it.
This is disappointing, if the aim was to see a balanced summary of previous
discussions. However, this particular gripe is a common issue with our
RFCs as a whole.Personally, regardless of the content of the RFC, I feel that the choice is
obvious. I’m just a little concerned about the lack of quality from both
“sides” in presenting their argument(s), or not.
I actually think that both perception and facts need to be take into account on naming/version number decisions. 
I must say I do share the perception that many version 6’s in open-source have been failures and I’ve heard many people ridiculing the PHP 6 is like Perl 6. So I don’t think it’s irrelevant. - This is perception but it matters.
Fact - There is SO much PHP 6 content out there and many folks think they know what PHP 6 is that I think the confusion we’d be creating in calling this PHP 6 would be huge and unnecessary. To the point I am even surprised we have folks here who are resisting not calling it PHP 6. It feels pretty obvious to me that we are doing people a disservice calling it PHP 6.
But anyway, didn’t want to restart the discussion but just wanted to point out that RFC should address both perception and fact because both matter. It’s not just a technical discussion.
Andi
The argument for PHP 6 is very short and reads half-baked. The
overwhelming majority of this very short section of the RFC is spent
describing how naming the release “PHP 6” will be a problem, with a very
wishy-washy conclusion that the author “expects” and “thinks” it won’t end
up being a problem. The PHP 6 section makes no attempt to provide counter
points to things mentioned in the following section, nor really attempts to
make any strong point at all.
While I'm obviously biased, I have to say that the only arguments for 
PHP 6 that came up in all of the discussions that ensued in internals@ 
(there were several) were that "it's the right thing to do" and 
"there's no reason not to do it".  Perhaps another argument was to 
'punish' book authors that prematurely published PHP 6 books.
It also contains, IMO unnecessarily, light-hearted and jokey comments not
befitting an RFC — unless you see the RFC as a joke too ;) — about 6 being
a failed version in other software, and 7 a lucky number. Seriously?..
I agree with everything Andi said about the perception of version 6, 
and I heard people joking about 6 being a graveyard number for 
languages too.  PHP 6 is very much associated with failure in many 
peoples minds, Perl 6 and to a lesser degree MySQL 6 as well - and as 
Andi said, perception matters a lot.
Regarding 7 being a lucky number, I thought it was fairly clear that 
it was said in humor, although there's a grain of positive perception 
here too...  I left off it being a prime number :)
The RFC as a whole is very light on trying to summarise, or at least
provide reference to, the history of "PHP 6” and discussions around it.
This is disappointing, if the aim was to see a balanced summary of previous
discussions. However, this particular gripe is a common issue with our
RFCs as a whole.
I think that this can be found fairly easily on the web...  But you're 
right that there is a hidden assumption that would be voters know the 
story.
Zeev
The poll is now open: https://wiki.php.net/rfc/php6#vote
Voting shall end in a week’s time on 2014-07-27.
I’ve cancelled the vote because I don’t think the case for 6 is sufficiently fleshed out. The RFC is now massively imbalanced in favour of 7, which isn’t really fair to the 6 side, and I don’t think we can hold a vote while that’s still the case.
Unfortunately I’m not terribly good at making such a case, so help in developing the 6 side would be appreciated. I won’t reopen the vote until the 6 side is sufficiently developed.
Thanks.
Andrea Faulds 
http://ajf.me/
The poll is now open: https://wiki.php.net/rfc/php6#vote
Voting shall end in a week’s time on 2014-07-27.
I’ve cancelled the vote because I don’t think the case for 6 is
sufficiently fleshed out. The RFC is now massively imbalanced in
favour of 7, which isn’t really fair to the 6 side, and I don’t think
we can hold a vote while that’s still the case.Unfortunately I’m not terribly good at making such a case, so help in
developing the 6 side would be appreciated. I won’t reopen the vote
until the 6 side is sufficiently developed.
Huh what? This is like you weren't happy with the way how the vote was 
going so you cancelled it? What nonsense.
cheers, 
Derick
Huh what? This is like you weren't happy with the way how the vote was
going so you cancelled it? What nonsense.
That is not why I cancelled the vote and I would appreciate it if people would stop insinuating as much.
Andrea Faulds 
http://ajf.me/
The poll is now open: https://wiki.php.net/rfc/php6#vote
Voting shall end in a week’s time on 2014-07-27.
I’ve cancelled the vote because I don’t think the case for 6 is
sufficiently fleshed out. The RFC is now massively imbalanced in
favour of 7, which isn’t really fair to the 6 side, and I don’t think
we can hold a vote while that’s still the case.Unfortunately I’m not terribly good at making such a case, so help in
developing the 6 side would be appreciated. I won’t reopen the vote
until the 6 side is sufficiently developed.Huh what? This is like you weren't happy with the way how the vote was
going so you cancelled it? What nonsense.
After the vote has been started the RFC was edited by Zeev in order to 
strengthen the case for PHP 7. There is nothing wrong with that, adding 
additional arguments to an RFC is perfectly fine by me.
However at the same time a number of paragraphs were removed that were 
arguing for PHP 6, at least in part. The only thing that was left in "The 
case for PHP 6" was a single paragraph, of which half was really just an 
explanation of the general situation.
Effectively the edits made the RFC text heavily biased. It's okay to edit 
an RFC to add arguments for your side, but I find it discourteous and 
disingenuous to remove arguments from the opposing side at the same time.
As such I can understand Andrea's decision to close this vote until tempers 
had time to cool down and both sides had a chance to be fairly represented.
Nikita
After the vote has been started the RFC was edited by Zeev in order to strengthen the case for PHP 7. There is nothing wrong with that, adding additional arguments to an RFC is perfectly fine by me.
However at the same time a number of paragraphs were removed that were arguing for PHP 6, at least in part. The only thing that was left in "The case for PHP 6" was a single paragraph, of which half was really just an explanation of the general situation.
Effectively the edits made the RFC text heavily biased. It's okay to edit an RFC to add arguments for your side, but I find it discourteous and disingenuous to remove arguments from the opposing side at the same time.
As such I can understand Andrea's decision to close this vote until tempers had time to cool down and both sides had a chance to be fairly represented.
It also wasn’t really fair of me to start a vote when there wasn’t really a case for 7, now that I think about it. I suppose that makes my later decision hypocritical, but it does mean we’re in a better place now when we have a second vote, as we have two cases.
-- 
Andrea Faulds 
http://ajf.me/
After the vote has been started the RFC was edited by Zeev in order to
strengthen the case for PHP 7. There is nothing wrong with that, adding
additional arguments to an RFC is perfectly fine by me.However at the same time a number of paragraphs were removed that were
arguing for PHP 6, at least in part. The only thing that was left in "The
case for PHP 6" was a single paragraph, of which half was really just an
explanation of the general situation.Effectively the edits made the RFC text heavily biased. It's okay to
edit an RFC to add arguments for your side, but I find it discourteous and
disingenuous to remove arguments from the opposing side at the same time.As such I can understand Andrea's decision to close this vote until
tempers had time to cool down and both sides had a chance to be fairly
represented.It also wasn’t really fair of me to start a vote when there wasn’t really
a case for 7, now that I think about it. I suppose that makes my later
decision hypocritical, but it does mean we’re in a better place now when we
have a second vote, as we have two cases.
To sum it up:
6 would be the logical number for the next major version, that's just a 
fact. 
I would go with it. But I and probably most others who would go with 6 
wouldn't really be hurt if we went with 7.
On the other hand there would be quite some people hurt if we went with 6. 
So, maybe it's just me,  but there seems to only be a "case" for 7.
Let's think about the people, not only numbers and facts. We often forget 
about that when "just" answering mails.
Cheers, 
Mike
After the vote has been started the RFC was edited by Zeev in order to
strengthen the case for PHP 7. There is nothing wrong with that, adding
additional arguments to an RFC is perfectly fine by me.However at the same time a number of paragraphs were removed that were
arguing for PHP 6, at least in part. The only thing that was left in "The
case for PHP 6" was a single paragraph, of which half was really just an
explanation of the general situation.Effectively the edits made the RFC text heavily biased. It's okay to
edit an RFC to add arguments for your side, but I find it discourteous and
disingenuous to remove arguments from the opposing side at the same time.As such I can understand Andrea's decision to close this vote until
tempers had time to cool down and both sides had a chance to be fairly
represented.It also wasn’t really fair of me to start a vote when there wasn’t really
a case for 7, now that I think about it. I suppose that makes my later
decision hypocritical, but it does mean we’re in a better place now when we
have a second vote, as we have two cases.To sum it up:
6 would be the logical number for the next major version, that's just a
fact.
I would go with it. But I and probably most others who would go with 6
wouldn't really be hurt if we went with 7.On the other hand there would be quite some people hurt if we went with 6.
So, maybe it's just me, but there seems to only be a "case" for 7.Let's think about the people, not only numbers and facts. We often forget
about that when "just" answering mails.Cheers,
Mike
Andrea and Zeev,
If it's not too much trouble, could you both keep us updated on this thread 
with regard to your progress (or lack thereof) in getting the RFC to a 
state that both of you are in agreement on?  I think part of the problem 
last time was that the discussion fizzled, people forgot about it and moved 
on to other things, then suddenly it sprang back up to a vote.  I know that 
added to the initial confusion on my part, at least.
So even if you've made no progress, please take a moment at least once a 
week or so to update this thread with your status.  It's kinda an 
accountability booster, as well.  And Andrea, though according to the 
bylaws you can start the vote whenever you want, please do me a favor and 
refrain from doing so until Zeev says his part is ready.  We can always put 
pressure on him and ultimately find someone else to do it if he takes too 
long, but as he pointed out and I think rightly so, there's no urgency at 
the moment so we can afford a little bit of foot-dragging if need be.
Oh and please feel free to tell me to butt-out at any time. =)
--Kris
-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Tuesday, July 22, 2014 8:59 AM
To: Michael Wallner
Cc: Andrea Faulds; PHP Internals; Derick Rethans; Nikita Popov
Subject: Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHPAndrea and Zeev,
If it's not too much trouble, could you both keep us updated on this
thread
with regard to your progress (or lack thereof) in getting the RFC to a
state that
both of you are in agreement on?
I made some more edits and I think the Case for 7 is ready.
We're ready to go to a vote as early as tomorrow as far as I'm concerned...
Zeev
I made some more edits and I think the Case for 7 is ready.
We're ready to go to a vote as early as tomorrow as far as I'm concerned…
I quite like what you’ve done to the PHP 6 section, it’s much nicer than it was before, thanks!
With the RFC as it is, I’d also be happy to go to a vote tomorrow.
-- 
Andrea Faulds 
http://ajf.me/
-----Original Message-----
From: Andrea Faulds [mailto:ajf@ajf.me]
Sent: Tuesday, July 22, 2014 5:42 PM
To: Zeev Suraski
Cc: Kris Craig; PHP Internals
Subject: Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHPI made some more edits and I think the Case for 7 is ready.
We're ready to go to a vote as early as tomorrow as far as I'm
concerned.I quite like what you've done to the PHP 6 section, it's much nicer than
it was
before, thanks!
You're welcome!  But really, the glory belongs to Nikita - he rewrote this 
section (and moved it below the Case for 7, for whatever reasons :)
With the RFC as it is, I'd also be happy to go to a vote tomorrow.
Consensus - yay!
Zeev
You're welcome! But really, the glory belongs to Nikita - he rewrote this
section (and moved it below the Case for 7, for whatever reasons :)
Actually, I moved it below the Case for 7, because I realised that most of the case for PHP 6 is just rebutting the case for 7, so it should really come afterwards.
-- 
Andrea Faulds 
http://ajf.me/
However at the same time a number of paragraphs were removed that were
arguing for PHP 6, at least in part. The only thing that was left in "The
case for PHP 6" was a single paragraph, of which half was really just an
explanation of the general situation.Effectively the edits made the RFC text heavily biased. It's okay to edit
an RFC to add arguments for your side, but I find it discourteous and
disingenuous to remove arguments from the opposing side at the same time.
Again this was mainly me replacing the not-so-convincing case for PHP 
7 (that's how these two paragraphs were referred to when they were 
added, after my complaints about the RFC being one sided PHP 6 only, 
you can check the archives) with a more convincing one.  But I'm of 
course fine with them being re-added if the proponents of 6 it helps 
illustrate the case.
I do think that it was a bit problematic that when I asked to restart 
the vote it was rejected, but as the vote leaned heavily towards 7 (it 
was 25 to 15 right before it was stopped, with 7 gaining very rapidly)
- it was done. But, I don't view it as a huge deal.
As such I can understand Andrea's decision to close this vote until tempers
had time to cool down and both sides had a chance to be fairly represented.
As I said weeks ago, I think we need the best case for 6 and the best 
case for 7, and put it up for a vote.  I would appreciate it if we 
didn't wait indefinitely for that, after spending much of my morning 
getting shouted at for frantically typing this RFC up instead of 
getting my daughters to kindergarten :)
Zeev
However at the same time a number of paragraphs were removed that were
arguing for PHP 6, at least in part. The only thing that was left in "The
case for PHP 6" was a single paragraph, of which half was really just an
explanation of the general situation.Effectively the edits made the RFC text heavily biased. It's okay to edit
an RFC to add arguments for your side, but I find it discourteous and
disingenuous to remove arguments from the opposing side at the same time.Again this was mainly me replacing the not-so-convincing case for PHP
7 (that's how these two paragraphs were referred to when they were
added, after my complaints about the RFC being one sided PHP 6 only,
you can check the archives) with a more convincing one. But I'm of
course fine with them being re-added if the proponents of 6 it helps
illustrate the case.I do think that it was a bit problematic that when I asked to restart
the vote it was rejected, but as the vote leaned heavily towards 7 (it
was 25 to 15 right before it was stopped, with 7 gaining very rapidly)
- it was done. But, I don't view it as a huge deal.
As such I can understand Andrea's decision to close this vote until
tempers
had time to cool down and both sides had a chance to be fairly
represented.As I said weeks ago, I think we need the best case for 6 and the best
case for 7, and put it up for a vote. I would appreciate it if we
didn't wait indefinitely for that, after spending much of my morning
getting shouted at for frantically typing this RFC up instead of
getting my daughters to kindergarten :)Zeev
--
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.
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.
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.
--Kris
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 – a note from Andrea 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’ve covered the PHP 7 issue more now.
The removed paragraphs were actually the RFC’s ‘case for PHP 7’.  As the 
champion for the PHP 7 case, I was 100.0% entitled to remove it as I 
thought it wasn’t doing a good job at presenting that case, and replace 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 ‘camp’ is good with the post-edits RFC (as they 
were substantial), and then restart the vote.  Andrea initially didn’t 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’t.   Note that even after she restored the edits, she didn’t 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 ‘case for PHP 7’ 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’d notice 
some issues elsewhere too:
- 
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 ‘case for PHP 7’ that was added there by PHP 6 proponents, is 
now turning out to be a further case for PHP 6.
- 
When I asked the vote to be canceled, it was rejected – even
though 20 people voted on a 100.0% one sided RFC before I put in a real 
case for 7.  Let’s say it was wrong for me to edit these two paragraphs 
into a real case for 7 – 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?
- 
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’t feel they 
were doing a good job representing the case for 6.
On my side, I don’t feel I did anything wrong.  I edited paragraphs 
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’m 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’s no need to delay on my account, we’re carrying on – 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’re talking about universal rules for RFCs – a ‘choose between a and 
b’ RFC should never go into a vote with one of the cases clearly 
misrepresented in it.  The ones to judge whether it’s properly represented 
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
Now let’s focus on bringing this to revote and being done with it.  And 
getting the kids to kindergarten J
Zeev
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’d 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.
The vote started with no real case for PHP 7 in there. I madeit clear in past weeks I intended to write one, and said it would take
time. The supposed ‘case for PHP 7’ 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.
When I asked the vote to be canceled, it was rejected – eventhough 20 people voted on a 100.0% one sided RFC before I put in a real
case for 7. Let’s say it was wrong for me to edit these two paragraphs
into a real case for 7 – 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?
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.
Fact it that when the vote was canceled, it was 25/15 in favorof 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’t 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’t 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’m 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.
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 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’s no need to delay on my account, we’re carrying on – 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’re talking about universal rules for RFCs – a ‘choose between a and
b’ RFC should never go into a vote with one of the cases clearly
misrepresented in it. The ones to judge whether it’s properly represented
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
Now let’s 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
The vote started with no real case for PHP 7 in there. I madeit clear in past weeks I intended to write one, and said it would take
time. The supposed ‘case for PHP 7’ 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.
Since the ORIGINAL RFC was for 'PHP6' or 'Not PHP6' without any 
particular proposed alternative it was basically already floored. Many 
of the reasons for not using PHP6 were all about breaking the versioning 
system. Currently the debate has changed and the question left is a 
simple one. Did PHP6 ever exist as a version? Since even the case for 
using PHP6 states the fact that PHP6 was abandoned in 2010 it does 
acknowledge that PHP6 has already been used as a version, so weakens 
it's own case. Removing that statement now would be inappropriate? So 
the discussion is not so much PHP6 or PHP7, but rather do we reopen the 
PHP6 branch again ... or honour the previous closing of that branch.
-- 
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact 
L.S.Caine Electronic Services - http://lsces.co.uk 
EnquirySolve - http://enquirysolve.com/ 
Model Engineers Digital Workshop - http://medw.co.uk 
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
The removed paragraphs were actually the RFC’s ‘case for PHP 7’. As the
champion for the PHP 7 case, I was 100.0% entitled to remove it as I
thought it wasn’t doing a good job at presenting that case, and replace it
with some real pro-7 content.
The original RFC had only one section where the advantages and 
disadvantages of PHP 6 vs PHP 7 were outlined in a back-and-forth 
discussion. Arguments for PHP 6 and PHP 7 were mixed.
When you created the separate section for PHP 7, you removed some of those 
mixed paragraphs and added the pro-7 arguments to the new section. The 
pro-6 arguments however were simply dropped. That is what I was referring 
to in my mail. An example of text that was simply removed from the RFC:
Another point that has been made is that due to online reviews, it would
quickly become clear that these old "PHP 6" books do not cover the new PHP
6; people would likely try them, find the code in the book did not work,
and rate the book "1 star", deterring other customers. Furthermore, the PHP
community would likely try to dissuade people from buying these old "PHP 6"
books. Some also question how many of the old "PHP 6" books are still in
print, for that matter.
To me this sounds quite clearly like an argument being made in favor of PHP 
6 and it was dropped during your revisions.
I'm not saying that you did this on purpose, quite likely you just dropped 
some PHP 7 related paragraphs without looking at them too closely, but the 
result is the same: An RFC that is very biased towards one side. I am also 
not denying that the RFC before your changes was biased to the other side. 
I think we all agree that this vote was somewhat rushed ;)
Nikita
The poll is now open: https://wiki.php.net/rfc/php6#vote
Voting shall end in a week’s time on 2014-07-27.
I’ve cancelled the vote because I don’t think the case for 6 is
sufficiently fleshed out. The RFC is now massively imbalanced in
favour of 7, which isn’t really fair to the 6 side, and I don’t think
we can hold a vote while that’s still the case.Unfortunately I’m not terribly good at making such a case, so help in
developing the 6 side would be appreciated. I won’t reopen the vote
until the 6 side is sufficiently developed.Huh what? This is like you weren't happy with the way how the vote was
going so you cancelled it? What nonsense.
Please get the facts straight before commenting.
I am astonishes to see so much energy spent on a such non critical topic. 
From people who should really spend more time actually discussing what will 
be php next (which should be much more more than just perf improvement). 
This is disappointing. Even more to see the RFC process being tricked out 
again.