[VOTE][RFC] Name of Next Release of PHP

php.internals

Andrew Faulds

12 years ago
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/

Zeev Suraski

12 years ago
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

Zeev Suraski

12 years ago
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 PHP > > 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/ > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
visit:

Andrew Faulds

12 years ago
On 20 Jul 2014, at 07:08, Zeev Suraski <zeev@zend.com> wrote:
> 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/

Zeev Suraski

12 years ago
> > 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

Andrew Faulds

12 years ago
On 20 Jul 2014, at 13:58, Zeev Suraski <zeev@zend.com> wrote:
> 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/

Lester Caine

12 years ago
On 20/07/14 07:08, Zeev Suraski wrote:
> 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

Peter Cowburn

12 years ago
On 20 July 2014 00:26, Andrea Faulds <ajf@ajf.me> wrote:
> 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.

Andrew Faulds

12 years ago
On 20 Jul 2014, at 16:39, Peter Cowburn <petercowburn@gmail.com> wrote:
> 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/

Andrew Faulds

12 years ago
On 20 Jul 2014, at 16:43, Andrea Faulds <ajf@ajf.me> wrote:
> > On 20 Jul 2014, at 16:39, Peter Cowburn <petercowburn@gmail.com> wrote: > >> 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/

Zeev Suraski

12 years ago
> On 20 ביול 2014, at 18:51, Andrea Faulds <ajf@ajf.me> wrote: > >> 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

Andi Gutmans

12 years ago
On Jul 20, 2014, at 8:39 AM, Peter Cowburn <petercowburn@gmail.com> wrote:
> > 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

Zeev Suraski

12 years ago
> On 20 ביול 2014, at 18:40, Peter Cowburn <petercowburn@gmail.com> wrote: > > 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

Andrew Faulds

12 years ago
On 20 Jul 2014, at 00:26, Andrea Faulds <ajf@ajf.me> wrote:
> 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/

Lester Caine

12 years ago
On 20/07/14 16:55, Andrea Faulds wrote:
>> 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.
Andrea - surely by now you have seen that there is very little reason to create yet another PHP6 branch at this time? What else CAN be said in favour of reopening something that has already been closed ...
-- 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

Derick Rethans

12 years ago
On Sun, 20 Jul 2014, Andrea Faulds wrote:
> > On 20 Jul 2014, at 00:26, Andrea Faulds <ajf@ajf.me> wrote: > > > 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

Andrew Faulds

12 years ago
On 20 Jul 2014, at 22:13, Derick Rethans <derick@php.net> wrote:
> 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/

Nikita Popov

12 years ago
On Sun, Jul 20, 2014 at 11:13 PM, Derick Rethans <derick@php.net> wrote:
> On Sun, 20 Jul 2014, Andrea Faulds wrote: > > > > > On 20 Jul 2014, at 00:26, Andrea Faulds <ajf@ajf.me> wrote: > > > > > 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

Andrew Faulds

12 years ago
On 20 Jul 2014, at 22:28, Nikita Popov <nikita.ppv@gmail.com> wrote:
> 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/

Michael Wallner

12 years ago
On 20 Jul 2014 23:32, "Andrea Faulds" <ajf@ajf.me> wrote:
> > > On 20 Jul 2014, at 22:28, Nikita Popov <nikita.ppv@gmail.com> wrote: > > > 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

Kris Craig

12 years ago
On Mon, Jul 21, 2014 at 2:21 AM, Michael Wallner <mike@php.net> wrote:
> On 20 Jul 2014 23:32, "Andrea Faulds" <ajf@ajf.me> wrote: > > > > > > On 20 Jul 2014, at 22:28, Nikita Popov <nikita.ppv@gmail.com> wrote: > > > > > 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

Zeev Suraski

12 years ago
> -----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 PHP > > > 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 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

Andrew Faulds

12 years ago
On 22 Jul 2014, at 15:38, Zeev Suraski <zeev@zend.com> wrote:
> 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/

Zeev Suraski

12 years ago
> -----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 PHP > > > On 22 Jul 2014, at 15:38, Zeev Suraski <zeev@zend.com> wrote: > > > 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!
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

Zeev Suraski

12 years ago
> On 21 ביול 2014, at 00:29, Nikita Popov <nikita.ppv@gmail.com> wrote: > > 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

Kris Craig

12 years ago
On Sun, Jul 20, 2014 at 2:46 PM, Zeev Suraski <zeev@zend.com> wrote:
> > On 21 ביול 2014, at 00:29, Nikita Popov <nikita.ppv@gmail.com> wrote: > > > > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
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

Zeev Suraski

12 years ago
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: 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 ‘case for PHP 7’ 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 – 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? 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’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 6. Now let’s focus on bringing this to revote and being done with it. And getting the kids to kindergarten J Zeev

Kris Craig

12 years ago
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.
> 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 ‘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.
> 2. 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? >
You're right that the vote should've been cancelled-- or, more to the point, it never should've been initiated in the first place. I still don't like how you gutted the 6 paragraph. However, I'm also not happy that the vote was called before you'd had a chance to finish your section of the RFC. I don't think that either one justifies the other. They were both mistakes that we should learn from. And again, if I'd been paying closer attention and realized you hadn't completed your section yet, I would've been just as critical of Andrea for starting the vote before the RFC was ready. I can understand her eagerness to settle this issue and we certainly wouldn't want to have the vote delayed for months over this, but there was no need for it to be rushed like this. I don't think there would've been any harm in giving you an extra few weeks to get your section written, especially considering what you're dealing with over there right now with those missiles.
> 3. Fact it that when the vote was canceled, it was 25/15 in favor > of 7 and with 7 gaining rapidly (it was 7 to 13 ~12hrs earlier). Another > fact is that even once these paragraphs were restored, Andrea didn’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 > 6. > > 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

Lester Caine

12 years ago
On 21/07/14 08:41, Kris Craig wrote:
>> 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 ‘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

Nikita Popov

12 years ago
On Mon, Jul 21, 2014 at 7:56 AM, Zeev Suraski <zeev@zend.com> wrote:
> 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

Pierre Joye

12 years ago
On Jul 20, 2014 11:13 PM, "Derick Rethans" <derick@php.net> wrote:
> > On Sun, 20 Jul 2014, Andrea Faulds wrote: > > > > > On 20 Jul 2014, at 00:26, Andrea Faulds <ajf@ajf.me> wrote: > > > > > 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.

Rowan Collins

12 years ago
Andrea Faulds wrote (on 20/07/2014):
> 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.
I've only skim read the recent discussion, and the current state of the RFC, because I've been busy, and I only have a few minutes left of my lunch break now, but it occurred to me before, and is even more obvious now, that the RFC would be much better with a different structure. Currently, it's laid out in what you might call an "adversarial" style - arguments for one side, then arguments for the other; this doesn't lend itself well to summarising all the previous discussions, because it just reads as a discussion of its own. (Just to be clear here: I don't mean "adversarial" as any kind of criticism of the debate, just as a technical description of the RFC's style.) A vote in a situation like this should, if possible, be a means of measuring a consensus, not a replacement for one. We're not electing the next President of PHP, so everyone should be focussing on understanding the issues, not hoping that their side will win at the ballot box. I suggest a completely different structure, where the RFC is split instead into *topics* or *categories* of argument. Then the various points raised in debate can be laid out without judgement, and there is less need to repeat the view that point X is less important than point Y, since it is up to the reader to conclude that. There is no need to try and "win" each of these sections for one side or the other, as the reader is not being asked to tally up a number of points for and against, but to weigh up the whole situation. Here are some of the headings which could be included: - Consistency with previous release numbering - Consistency with other projects - Potential for confusion about reasons for the skip - Existing printed material from previous "PHP 6" - Existing online material from previous "PHP 6" (can be harder to date than printed material) - Mindshare of previous "PHP 6" (people who heard about it and still associate it with Unicode) - Existing material already mentioning the new version as "PHP 6" - Superstitions etc (which I'm guessing no one actually takes seriously) I think that covers everything from *both* sides of the current RFC, but there may be other things that came up in discussion that aren't mentioned because they don't fit well in the current structure. Regards,
-- Rowan Collins [IMSoP]

Andrew Faulds

12 years ago
On 22 Jul 2014, at 14:27, Rowan Collins <rowan.collins@gmail.com> wrote:
> the RFC would be much better with a different structure. Currently, it's laid out in what you might call an "adversarial" style - arguments for one side, then arguments for the other; this doesn't lend itself well to summarising all the previous discussions, because it just reads as a discussion of its own.
That’s actually what I’ve been thinking recently. Having a case for PHP 6 and a case for PHP 7 doesn’t really make much sense anyway, as all a case for PHP 6 needs to do is rebut the arguments for PHP 7, for the most part. Maybe if I have some time I’ll try to restructure the RFC.
-- Andrea Faulds http://ajf.me/

Jonny Stirling

12 years ago
On Tue, Jul 22, 2014 at 2:56 PM, Andrea Faulds <ajf@ajf.me> wrote:
> > On 22 Jul 2014, at 14:27, Rowan Collins <rowan.collins@gmail.com> wrote: > > Maybe if I have some time I’ll try to restructure the RFC. > -- > Andrea Faulds > http://ajf.me/ > >
Or, (maybe this is controversial in itself), drop the entire thing. Until there is in fact, a next major version, what its name will be is surely moot, and until there is a GA release (or at the earliest alphas / beta test releases), there should be no such thing as a versioned / numbered release. Assuming the above, there is no need to discuss / vote on this now, but in 1-3 years or so (depending on who you listen to ;)), and in that time frame, shouldn't it simply remain as PHP.next (or some random codename / whatever). There's a good chance that views will change in that time anyway and new / joining devs may wish to have their say, so surely don't version a non-version, and leave it till there's something to be officially released. Jonny Stirling

Andrew Faulds

12 years ago
On 22 Jul 2014, at 15:12, Jonny Stirling <phoenix@jonstirling.co.uk> wrote:
> Or, (maybe this is controversial in itself), drop the entire thing. > > Until there is in fact, a next major version, what its name will be is surely moot, and until there is a GA release (or at the earliest alphas / beta test releases), there should be no such thing as a versioned / numbered release. > > Assuming the above, there is no need to discuss / vote on this now, but in 1-3 years or so (depending on who you listen to ;)), and in that time frame, shouldn't it simply remain as PHP.next (or some random codename / whatever).
There is a good reason to do this now: to avoid having to bikeshed about it later.
-- Andrea Faulds http://ajf.me/

Jonny Stirling

12 years ago
On Tue, Jul 22, 2014 at 3:22 PM, Andrea Faulds <ajf@ajf.me> wrote:
> > On 22 Jul 2014, at 15:12, Jonny Stirling <phoenix@jonstirling.co.uk> > wrote: > > > Or, (maybe this is controversial in itself), drop the entire thing. > > > > Until there is in fact, a next major version, what its name will be is > surely moot, and until there is a GA release (or at the earliest alphas / > beta test releases), there should be no such thing as a versioned / > numbered release. > > > > Assuming the above, there is no need to discuss / vote on this now, but > in 1-3 years or so (depending on who you listen to ;)), and in that time > frame, shouldn't it simply remain as PHP.next (or some random codename / > whatever). > > There is a good reason to do this now: to avoid having to bikeshed about > it later. > > -- > Andrea Faulds > http://ajf.me/ >
That's not a good reason, and it doesn't avoid any such thing anyway I'm afraid. PHP6 / 7 / whatever, does not exist, and will not exist (like I said) until official releases as the next major version are put out. Tis a pretty simple solution for a problem that does not actually exist in the present.

Lester Caine

12 years ago
On 22/07/14 15:30, Jonny Stirling wrote:
> PHP6 / 7 / whatever, does not exist, and will not exist (like I said) until > official releases as the next major version are put out. Tis a pretty > simple solution for a problem that does not actually exist in the present.
PHP6 existed - it was simply never released formally even as an alpha due to the conflict between what was planned and how it was being implemented. There is a lot of material within the PHP archive which document it. SOME has been lost due to the various changes to the website handling, but that material is archived elsewhere. Now people are saying PHPNext, or PHP6/7 so extracting what relates to new discussions on the next version is a problem. phpng has provided another handle for these discussions, and that can be used to filter the growing volume of material, but there is not a suitable handle to lump the NEW discussions on PHPNext together. PHP7 is simply the next obvious hook given that PHP6 is contaminated with such a large existing history. Making a decision now simply clears up what is currently an untenable situation!
-- 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

Brian Moon

12 years ago
> Or, (maybe this is controversial in itself), drop the entire thing. > > Until there is in fact, a next major version, what its name will be is > surely moot, and until there is a GA release (or at the earliest alphas / > beta test releases), there should be no such thing as a versioned / > numbered release. > > Assuming the above, there is no need to discuss / vote on this now, but in > 1-3 years or so (depending on who you listen to ;)), and in that time > frame, shouldn't it simply remain as PHP.next (or some random codename / > whatever).
As I read this, it occurred to me that naming things before they are released is how we ended up in this situation to begin with. People started writing PHP6 books and doing talks at conferences before PHP6 even existed. What if the same thing happens with PHP7? Or it happens to PHP6 again? Right now, there is discussion about phpng being php-next. What if that is rolled in and later found that it was a bad idea? And there are talks and blog posts about "PHP7" that talk about phpng? With Phorum, we skipped version 2 and version 4 because of this issue. We named them, worked on them, and then decided they were bad directions. Those numbers were burned. If we had not named them to begin with, we would not have been in that boat. Brian Moon brianlmoon@php.net http://brian.moonspot.net/

Ferenc Kovacs

12 years ago
On Tue, Jul 22, 2014 at 4:35 PM, Brian Moon <brian@moonspot.net> wrote:
> Or, (maybe this is controversial in itself), drop the entire thing. >> >> Until there is in fact, a next major version, what its name will be is >> surely moot, and until there is a GA release (or at the earliest alphas / >> beta test releases), there should be no such thing as a versioned / >> numbered release. >> >> Assuming the above, there is no need to discuss / vote on this now, but in >> 1-3 years or so (depending on who you listen to ;)), and in that time >> frame, shouldn't it simply remain as PHP.next (or some random codename / >> whatever). >> > > As I read this, it occurred to me that naming things before they are > released is how we ended up in this situation to begin with. People started > writing PHP6 books and doing talks at conferences before PHP6 even existed. > What if the same thing happens with PHP7? Or it happens to PHP6 again? > Right now, there is discussion about phpng being php-next. What if that is > rolled in and later found that it was a bad idea? And there are talks and > blog posts about "PHP7" that talk about phpng? > > With Phorum, we skipped version 2 and version 4 because of this issue. We > named them, worked on them, and then decided they were bad directions. > Those numbers were burned. If we had not named them to begin with, we would > not have been in that boat. > > Brian Moon > brianlmoon@php.net > http://brian.moonspot.net/ > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
every branch has a version (main/php_version.h), phpng has 5.7.0 (because that is what master had when branched out). there are already some posts which refer to phpng as 5.7 ( http://www.reddit.com/r/PHP/comments/2arl1k/php_57_aka_phpng_is_now_nearly_twice_as_fast_as/ for example). so I think that it is a bit naive to think that we can wait until the last minute with coming up with the final release number, plus I think it is better to discuss and get consensus before we have time-pressure to do so.
-- Ferenc Kovács @Tyr43l - http://tyrael.hu

Zeev Suraski

12 years ago
> From: Andrea Faulds [mailto:ajf@ajf.me] > Sent: Tuesday, July 22, 2014 4:56 PM > To: Rowan Collins > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP > > Maybe if I have some time I'll try to restructure the RFC.
Please don't. I think the way it's laid out right now makes sense. Let's not try to sweep this under the carpet - we two mutually exclusive options and we need to decide between them. We agreed on a certain format, we agreed that each option will have its own section and that its proponents will write the best possible case for it - rebuttal or otherwise. Let's stick with this decision and move forward. To those who are saying 'let's bury it for now', I absolutely think we should go all the way and be done with it. In fact, had Andrea not bring it up a few weeks ago, I'd be bringing it up shortly after the PHPNG RFC. This has been a lingering question for a long time, and personally, I'm fed up with having to write 'PHP.NEXT', '.1', '.2', '6/7' and all sorts of other politically-correct version numbers. I think those who write 'PHP 6' or alternatively 'PHP 7' are being unfair until a decision has been taken. We've invested heavily in this in terms of discussion, we're not waiting for any additional data points and delaying the decision will do nothing but waste additional time in the future. Let's take a decision and be done with it. Zeev

Andrew Faulds

12 years ago
On 22 Jul 2014, at 15:48, Zeev Suraski <zeev@zend.com> wrote:
>> Maybe if I have some time I'll try to restructure the RFC. > > Please don’t.
I was going to, but I’m actually happy with it now, so I won’t bother.
> To those who are saying 'let's bury it for now', I absolutely think we > should go all the way and be done with it. In fact, had Andrea not bring > it up a few weeks ago, I'd be bringing it up shortly after the PHPNG RFC. > This has been a lingering question for a long time, and personally, I'm > fed up with having to write 'PHP.NEXT', '.1', '.2', '6/7' and all sorts of > other politically-correct version numbers. I think those who write 'PHP > 6' or alternatively 'PHP 7' are being unfair until a decision has been > taken. > > We've invested heavily in this in terms of discussion, we're not waiting > for any additional data points and delaying the decision will do nothing > but waste additional time in the future. > > Let's take a decision and be done with it.
This pretty much sums up my thoughts. I want this over with, if only so I won’t keep tripping up and saying PHP 6, then having to correct myself.
-- Andrea Faulds http://ajf.me/

Jonny Stirling

12 years ago
Maybe then an option should be added to vote "not now" or similar. You're forcing people into a decision for this or that when some may not wish for the decision to be made right now, and without the ability to abstain from either option. Neither of you are going to change your minds anyway, and since it's your choice, all I can do is make the points now in hopes that they'll make sense down the line. The reason for the provided post being 5.7 is because it wasn't changed when it really should have been and somebody took it to be literally without enough research. Fix the cause, not the effect, update the version file to be show that it's the ng dev branch. P.s. no complaining when the bike-shedding on this topic returns in a few years ;) Jonny. On Tue, Jul 22, 2014 at 3:48 PM, Zeev Suraski <zeev@zend.com> wrote:

Rowan Collins

12 years ago
Zeev Suraski wrote (on 22/07/2014):
> I think the way it's laid out right now makes sense. Let's not try to > sweep this under the carpet - we two mutually exclusive options and we > need to decide between them.
How is laying out the arguments more clearly "sweeping it under the carpet"? The *outcomes* may be mutually exclusive, but the *discussion* is about various issues, and I don't think the current RFC does a good job of summarising those. Note that I'm not asking for it to be expanded; in fact, I think it should be shorter, and stick to listing the key points - anyone wanting the details of particular people's views can check out the mailing list archives.

Zeev Suraski

12 years ago
> On 22 ביול 2014, at 19:25, Rowan Collins <rowan.collins@gmail.com> wrote: > > Zeev Suraski wrote (on 22/07/2014): >> I think the way it's laid out right now makes sense. Let's not try to >> sweep this under the carpet - we two mutually exclusive options and we >> need to decide between them. > > How is laying out the arguments more clearly "sweeping it under the carpet"?
If I understood you correctly you seem to believe that we should aim for consensus when it's pretty clear there isn't going to be one. I can't see how shuffling the points around under topics will somehow help us create such consensus. Knowing many of the people in the two 'camps', I know that's not going to happen. I also don't think it's going to make it any clearer. In fact I think that putting these arguments into topics that go back and forth arguing for 6 and 7 will actually make it a lot messier. It's not as if you can buy into one argument for 7 and then another one for 6 - voters need to make a choice between the two options. I think people should read one case, then the other, and see which one they like better as a whole, as opposed to a debate-style approach where each topic is discussed separately.
> The *outcomes* may be mutually exclusive, but the *discussion* is about various issues, and I don't think the current RFC does a good job of summarising those.
If you think there's missing or superfluous content in either cases I think we'd all appreciate any suggestions you may have. I don't think that changing format while keeping the content will change the job the RFC does at summarizing the issues. Also, judging by the core turnout a couple of days ago I think it's clear most people are ready to vote on this. In about 15 hrs it had more votes that some other RFCs don't have after a week. Zeev

Rowan Collins

12 years ago
Zeev Suraski wrote (on 22/07/2014):
> If I understood you correctly you seem to believe that we should aim > for consensus when it's pretty clear there isn't going to be one. I > can't see how shuffling the points around under topics will somehow > help us create such consensus. Knowing many of the people in the two > 'camps', I know that's not going to happen.
Yeah, I was just a bit non-plussed at how much this felt like an election targeting a few "floating voters", rather than actually seeking to understand other people's positions. But maybe it's just too late for that, and most people have made up their minds already anyway.
> I also don't think it's going to make it any clearer. In fact I think > that putting these arguments into topics that go back and forth > arguing for 6 and 7 will actually make it a lot messier.
To be fair, looking at the current content, you could more or less interleave the current bullets, since they refer to each other already. My thought was that doing so might reduce some repetition as they wouldn't need to reintroduce the same points in order to rebuff them, but it's not as bad as I thought. The PHP 7 section mostly looks longer because it has an intro and conclusion where the PHP 6 one doesn't. I got the vibe that people weren't happy with the RFC, and that's why the vote was cancelled, so I was suggesting a way forward, but maybe I misread the situation. Regards,
-- Rowan Collins [IMSoP]

Brian Moon

12 years ago
> I got the vibe that people weren't happy with the RFC, and that's why > the vote was cancelled, so I was suggesting a way forward, but maybe I > misread the situation.
I think that was 2 days and many, many emails ago. The parties that expressed an opinion on the RFC which led to the vote being cancelled are actually in agreement now. If we don't use a counterpoint style debate in the RFC, then '6' only has one bullet: * 6 is the next integer after 5. Brian Moon brianlmoon@php.net http://brian.moonspot.net/

Rowan Collins

12 years ago
Brian Moon wrote (on 22/07/2014):
>> I got the vibe that people weren't happy with the RFC, and that's why >> the vote was cancelled, so I was suggesting a way forward, but maybe I >> misread the situation. > > I think that was 2 days and many, many emails ago. The parties that > expressed an opinion on the RFC which led to the vote being cancelled > are actually in agreement now.
Ah, OK, my bad. :)
-- Rowan Collins [IMSoP]

Andrew Faulds

12 years ago
On 22 Jul 2014, at 18:21, Rowan Collins <rowan.collins@gmail.com> wrote:
> I got the vibe that people weren't happy with the RFC, and that's why the vote was cancelled, so I was suggesting a way forward, but maybe I misread the situation.
I cancelled it because Zeev’s edits took me by surprise. It was rather hypocritical of me, but I cancelled it. There was no other reason.
-- Andrea Faulds http://ajf.me/