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.