FAQ
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/

Search Discussions

  • Zeev Suraski at Jul 20, 2014 at 5:01 am
    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
    On 20 ביול 2014, at 02:26, Andrea Faulds 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?

    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: http://www.php.net/unsub.php
  • Zeev Suraski at Jul 20, 2014 at 6:09 am
    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
    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:
    http://www.php.net/unsub.php
  • Andrea Faulds at Jul 20, 2014 at 12:39 pm

    On 20 Jul 2014, at 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 :)
    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 at Jul 20, 2014 at 12:58 pm

    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
  • Andrea Faulds at Jul 20, 2014 at 1:00 pm

    On 20 Jul 2014, at 13:58, Zeev Suraski 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 at Jul 20, 2014 at 1:01 pm

    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 at Jul 20, 2014 at 3:40 pm

    On 20 July 2014 00:26, Andrea Faulds 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.

    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: http://www.php.net/unsub.php
  • Andrea Faulds at Jul 20, 2014 at 3:43 pm

    On 20 Jul 2014, at 16:39, Peter Cowburn 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/
  • Andrea Faulds at Jul 20, 2014 at 3:51 pm

    On 20 Jul 2014, at 16:43, Andrea Faulds wrote:

    On 20 Jul 2014, at 16:39, Peter Cowburn 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 at Jul 20, 2014 at 3:58 pm

    On 20 ביול 2014, at 18:51, Andrea Faulds 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 at Jul 20, 2014 at 4:11 pm

    On Jul 20, 2014, at 8:39 AM, Peter Cowburn 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 at Jul 20, 2014 at 9:36 pm

    On 20 ביול 2014, at 18:40, Peter Cowburn 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
  • Andrea Faulds at Jul 20, 2014 at 3:56 pm

    On 20 Jul 2014, at 00:26, Andrea Faulds 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 at Jul 20, 2014 at 9:07 pm

    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 at Jul 20, 2014 at 9:13 pm

    On Sun, 20 Jul 2014, Andrea Faulds wrote:

    On 20 Jul 2014, at 00:26, Andrea Faulds 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
  • Andrea Faulds at Jul 20, 2014 at 9:14 pm

    On 20 Jul 2014, at 22:13, Derick Rethans 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 at Jul 20, 2014 at 9:28 pm

    On Sun, Jul 20, 2014 at 11:13 PM, Derick Rethans wrote:
    On Sun, 20 Jul 2014, Andrea Faulds wrote:

    On 20 Jul 2014, at 00:26, Andrea Faulds 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
  • Andrea Faulds at Jul 20, 2014 at 9:32 pm

    On 20 Jul 2014, at 22:28, Nikita Popov 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 at Jul 21, 2014 at 9:21 am

    On 20 Jul 2014 23:32, "Andrea Faulds" wrote:
    On 20 Jul 2014, at 22:28, Nikita Popov 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 at Jul 22, 2014 at 5:59 am

    On Mon, Jul 21, 2014 at 2:21 AM, Michael Wallner wrote:
    On 20 Jul 2014 23:32, "Andrea Faulds" wrote:

    On 20 Jul 2014, at 22:28, Nikita Popov 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 at Jul 20, 2014 at 9:46 pm

    On 21 ביול 2014, at 00:29, Nikita Popov 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 at Jul 20, 2014 at 10:38 pm

    On Sun, Jul 20, 2014 at 2:46 PM, Zeev Suraski wrote:

    On 21 ביול 2014, at 00:29, Nikita Popov 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 at Jul 21, 2014 at 5:56 am
    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 at Jul 21, 2014 at 7:41 am
    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 at Jul 21, 2014 at 8:02 am

    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 at Jul 21, 2014 at 9:16 am

    On Mon, Jul 21, 2014 at 7:56 AM, Zeev Suraski 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 at Jul 21, 2014 at 6:09 am

    On Jul 20, 2014 11:13 PM, "Derick Rethans" wrote:
    On Sun, 20 Jul 2014, Andrea Faulds wrote:

    On 20 Jul 2014, at 00:26, Andrea Faulds 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJul 19, '14 at 11:26p
activeJul 22, '14 at 5:59a
posts28
users10
websitephp.net

People

Translate

site design / logo © 2017 Grokbase