FAQ
All,

In case there's any chance people lost track in the noise:

Please, please - vote No on https://wiki.php.net/rfc/size_t_and_int64_next#vote

We're in an unprecedented situation where almost all of the code
contributors to the engine are against a patch that is being forced on
them for no reason, negates months of hard work performed to get us
phpng, and is somehow enjoying a majority (almost exclusively from
people who are not engine contributors).

I urge everyone with a right to vote (and only those, as per
https://wiki.php.net/rfc/voting) to vote no, and even those who voted
yes to revert their votes to no.

We need your help!

Regards,

Zeev

Search Discussions

  • Anatol Belski at May 17, 2014 at 11:02 am

    On Sat, May 17, 2014 12:53, Zeev Suraski wrote:
    All,


    In case there's any chance people lost track in the noise:


    Please, please - vote No on
    https://wiki.php.net/rfc/size_t_and_int64_next#vote


    We're in an unprecedented situation where almost all of the code
    contributors to the engine are against a patch that is being forced on them
    for no reason, negates months of hard work performed to get us phpng, and
    is somehow enjoying a majority (almost exclusively from people who are not
    engine contributors).

    I urge everyone with a right to vote (and only those, as per
    https://wiki.php.net/rfc/voting) to vote no, and even those who voted
    yes to revert their votes to no.

    We need your help!
    Am i watching a CNN movie?

    Cheers

    Anatol
  • Zeev Suraski at May 17, 2014 at 11:13 am
    No, you're watching the Voting RFC going haywire.

    It's the second time we have an RFC that deals with internal
    implementation as opposed to features and functions, something the RFC
    process was never designed to do. And it appears to be failing, much
    like it almost failed the last time around.

    Last time it happened I raised the hope that non-engine contributors
    will refrain from placing votes on such RFCs, we may need to (try and)
    formalize it.

    Zeev

    On 17 במאי 2014, at 14:02, Anatol Belski wrote:

    On Sat, May 17, 2014 12:53, Zeev Suraski wrote:
    All,


    In case there's any chance people lost track in the noise:


    Please, please - vote No on
    https://wiki.php.net/rfc/size_t_and_int64_next#vote


    We're in an unprecedented situation where almost all of the code
    contributors to the engine are against a patch that is being forced on them
    for no reason, negates months of hard work performed to get us phpng, and
    is somehow enjoying a majority (almost exclusively from people who are not
    engine contributors).

    I urge everyone with a right to vote (and only those, as per
    https://wiki.php.net/rfc/voting) to vote no, and even those who voted
    yes to revert their votes to no.

    We need your help!
    Am i watching a CNN movie?

    Cheers

    Anatol
  • Anatol Belski at May 17, 2014 at 11:35 am

    On Sat, May 17, 2014 13:13, Zeev Suraski wrote:
    No, you're watching the Voting RFC going haywire.


    It's the second time we have an RFC that deals with internal
    implementation as opposed to features and functions, something the RFC
    process was never designed to do. And it appears to be failing, much like
    it almost failed the last time around.

    Last time it happened I raised the hope that non-engine contributors
    will refrain from placing votes on such RFCs, we may need to (try and)
    formalize it.

    Zeev


    On 17 במאי 2014, at 14:02, Anatol Belski wrote:

    On Sat, May 17, 2014 12:53, Zeev Suraski wrote:
    All,



    In case there's any chance people lost track in the noise:



    Please, please - vote No on
    https://wiki.php.net/rfc/size_t_and_int64_next#vote



    We're in an unprecedented situation where almost all of the code
    contributors to the engine are against a patch that is being forced on
    them for no reason, negates months of hard work performed to get us
    phpng, and is somehow enjoying a majority (almost exclusively from
    people who are not engine contributors).

    I urge everyone with a right to vote (and only those, as per
    https://wiki.php.net/rfc/voting) to vote no, and even those who voted
    yes to revert their votes to no.

    We need your help!
    Am i watching a CNN movie?


    Cheers


    Anatol
    Exactly, the single thing I see failing here is the voting RFC. Not
    because of itself, but because it's useless when it comes to the politics
    we have here. And that confrontations do actually much more harm than any
    technical issue ever.

    Regards

    Anatol
  • Pierre Joye at May 17, 2014 at 12:06 pm

    On Sat, May 17, 2014 at 12:53 PM, Zeev Suraski wrote:
    All,

    In case there's any chance people lost track in the noise:

    Please, please - vote No on https://wiki.php.net/rfc/size_t_and_int64_next#vote

    We're in an unprecedented situation where almost all of the code
    contributors to the engine are against a patch that is being forced on
    them for no reason, negates months of hard work performed to get us
    phpng, and is somehow enjoying a majority (almost exclusively from
    people who are not engine contributors).
    Have you really written "negates months of hard work"? I mean, really? :)


    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Andrea Faulds at May 17, 2014 at 2:33 pm

    On 17 May 2014, at 11:53, Zeev Suraski wrote:

    Please, please - vote No on https://wiki.php.net/rfc/size_t_and_int64_next#vote
    Everyone, please vote yes. The No side is unlikely to lose, due to the 2/3 majority required. The Yes side does need a lot of help to win, though. Remember, every no vote requires 2 yes votes to counteract it.
    We're in an unprecedented situation where almost all of the code
    contributors to the engine are against a patch that is being forced on
    them for no reason, negates months of hard work performed to get us
    phpng, and is somehow enjoying a majority (almost exclusively from
    people who are not engine contributors).
    It negates months of hard work performed behind closed doors in secret (phpng), compared to lots of hard work done in the open (64-bit patch).
    I urge everyone with a right to vote (and only those, as per
    https://wiki.php.net/rfc/voting) to vote no, and even those who voted
    yes to revert their votes to no.

    No way. Let’s use the right types for the job. ‘int’ and ‘long’ should never be used for sizes of data structures.

    It’s not as if 64-bit will kill phpng, it’ll just delay it.
    --
    Andrea Faulds
    http://ajf.me/
  • Zeev Suraski at May 17, 2014 at 3:37 pm
    On 17 במאי 2014, at 17:32, Andrea Faulds wrote:


    Everyone, please vote yes. The No side is unlikely to lose, due to the 2/3
    majority required. The Yes side does need a lot of help to win, though.
    Remember, every no vote requires 2 yes votes to counteract it.


    That has nothing to do with the fact applying this patch is morally wrong,
    and also may or may not be true.


    It negates months of hard work performed behind closed doors in secret
    (phpng), compared to lots of hard work done in the open (64-bit patch).


    Unlike phpng, this is a tactical patch that while changes a lot of code, is
    mostly about "dirty work" than research.

    Have you used PHP 3? Then maybe 4? Surely 5?

    All were developed in exactly the same way. First a working PoC was
    established, after lots of trial and error and hard work it was shared with
    everyone to join in.

    Spinning phpng's work as something evil is as ridiculous as it is wrong.
      Sabotaging it because of it is even worse.

    No way. Let’s use the right types for the job. ‘int’ and ‘long’ should
    never be used for sizes of data structures.


    This is ridiculous. But I'm sure you know a lot better than Andi, Derick,
    Dmitry, Nikita, Rasmus, Stas, Xinchen and myself. I fail to understand who
    in his rift mins thinks it's both technically and morally legitimate to
    force this patch on this group.

    It’s not as if 64-bit will kill phpng, it’ll just delay it.


    You don't seem to realize what's going on here. It won't delay it, it'll
    greatly slow it down, and given phpng is all about performance - it negates
    its goals. Phpng's key performance gain had to do with compacting it's
    data structures. This goes in the opposite direction, 180 degrees.
      There's no way to fix it later as some suggest, it's an inherent
    incompatibility in directions.

    For the current PHP it yields an 8% memory increase. For phpng it'll be a
    lot more since it's data structures are more compact and therefore it'll be
    a lot more, relatively speaking.

    Zeev
  • Andrea Faulds at May 17, 2014 at 3:46 pm

    On 17 May 2014, at 16:37, Zeev Suraski wrote:

    On 17 במאי 2014, at 17:32, Andrea Faulds wrote:

    Everyone, please vote yes. The No side is unlikely to lose, due to the 2/3 majority required. The Yes side does need a lot of help to win, though. Remember, every no vote requires 2 yes votes to counteract it.
    That has nothing to do with the fact applying this patch is morally wrong, and also may or may not be true.
    Morally wrong? I don’t see how morals come into this. Yes, it would undo some work that has been done by you, in favour of someone else’s work. But I don’t see what’s ‘wrong’ about that.
    Spinning phpng's work as something evil is as ridiculous as it is wrong. Sabotaging it because of it is even worse.
    I never said phpng was evil. I said it was developed behind closed doors.

    You, on the other hand, just said that the 64-bit patch is evil ("applying this patch is morally wrong”). Two can play at this game.

    “Spinning the 64-bit patch as something evil is as ridiculous as it is wrong.”
    You don't seem to realize what's going on here. It won't delay it, it'll greatly slow it down, and given phpng is all about performance - it negates its goals. Phpng's key performance gain had to do with compacting it's data structures. This goes in the opposite direction, 180 degrees. There's no way to fix it later as some suggest, it's an inherent incompatibility in directions.

    For the current PHP it yields an 8% memory increase. For phpng it'll be a lot more since it's data structures are more compact and therefore it'll be a lot more, relatively speaking.
    Relatively, yes. In absolute terms, however, what is the gap between vanilla and phpng + 64bit patch?

    --
    Andrea Faulds
    http://ajf.me/
  • Zeev Suraski at May 17, 2014 at 4:03 pm

    That has nothing to do with the fact applying this patch is morally wrong, and also may or may not be true.
    Morally wrong? I don’t see how morals come into this. Yes, it would undo some work that has been done by you, in favour of someone else’s work. But I don’t see what’s ‘wrong’ about that.
    Between the list of names I wrote, you have 80-90% of the engine code
    if not more. The yes group is - for the most part - comprised of non
    engine contributors, which are forcing their will on the ones who are.
      I'm not saying these guys aren't PHP contributors, btw. But much
    like I wouldn't dream of telling the docs team how they should do
    their job, I don't expect the opposite to happen either.
    I never said phpng was evil. I said it was developed behind closed doors.
    You suggested it was somehow inferior because of that, not just stating a fact.
    For the current PHP it yields an 8% memory increase. For phpng it'll be a lot more since it's data structures are more compact and therefore it'll be a lot more, relatively speaking.
    Relatively, yes. In absolute terms, however, what is the gap between vanilla and phpng + 64bit patch?
    We don't have any numbers about phpng plus the patch because it
    doesn't yet exist. My guess is that it'll be in the 20-30% range to
    add this patch to phpng. Comparing to vanilla doesn't make sense at
    all - we didn't work phpng to waste the gains on this patch - but to
    improve performance.

    Zeev
  • Bruno at May 17, 2014 at 6:31 pm

    Le 17 mai 2014 à 18:03, Zeev Suraski a écrit :

    But much
    like I wouldn't dream of telling the docs team how they should do
    their job, I don't expect the opposite to happen either.
    So if I understand you suggest that only core developers should decide for core modifications ? Isn’t it against the voting RFC which you’re one of the authors ?

    That’s a really weird vision of an open source community for me.
  • Zeev Suraski at May 17, 2014 at 6:43 pm

    -----Original Message-----
    From: bruno@chalopin.fr
    Sent: Saturday, May 17, 2014 9:31 PM
    To: PHP internals
    Subject: Re: [PHP-DEV] A call for help (urgent)


    Le 17 mai 2014 à 18:03, Zeev Suraski <zeev@zend.com> a écrit :
    But much
    like I wouldn't dream of telling the docs team how they should do
    their job, I don't expect the opposite to happen either.
    So if I understand you suggest that only core developers should decide for core
    modifications ? Isn’t it against the voting RFC which you’re one of the
    authors ?

    It may be against what’s written there (which is why I need to beg as
    opposed to just point people to it) - but not its spirit.
    The voting RFC was written with language functions, features and processes
    in mind. Not implementation. Things like Traits - which most certainly
    involves Core, or return type hinting - these are the things the Voting
    RFC was created for. As you pointed out, I'm one who those who wrote much
    of the text of it, I should know.

    I didn't even dream that we'll have RFCs that deal with low-level
    implementation up for vote. If I did, there'd be a separate dedicated
    section for it.
    That’s a really weird vision of an open source community for me.
    It actually isn't. Open Source is typically some form of meritocracy, and
    those who have merit in a given component are those who own it. The RFC
    process was designed to give a wider range of 'stakeholders' a say in the
    language direction - and I think it greatly helped PHP in the last few
    years. However it was never designed to give those stakeholders a say
    about its implementation. Unfortunately, I wasn't sufficiently
    forward-looking to make that clear in the RFC. I still think this can
    work without changes to the Voting RFC, again, assuming people do not vote
    on implementation RFCs that don't directly concern the parts of the code
    they own.

    Zeev
  • Ulf Wendel at May 19, 2014 at 10:04 pm

    Am 17.05.2014 20:31, schrieb bruno@chalopin.fr:

    Le 17 mai 2014 à 18:03, Zeev Suraski <zeev@zend.com> a écrit :
    But much
    like I wouldn't dream of telling the docs team how they should do
    their job, I don't expect the opposite to happen either.
    So if I understand you suggest that only core developers should decide for core modifications ? Isn’t it against the voting RFC which you’re one of the authors ?

    That is not the point.

    Name the feature you want, vote on the feature as such but don't force
    the ones in the know to use the implemention you consider optimal. Trust
    the experts on the details.

    Ulf
  • Pierre Joye at May 17, 2014 at 5:59 pm

    On May 17, 2014 5:38 PM, "Zeev Suraski" wrote:
    On 17 במאי 2014, at 17:32, Andrea Faulds wrote:

    That has nothing to do with the fact applying this patch is morally wrong,
    and also may or may not be true.
    Morally wrong? But doing months of Dev in secret while knowing that we work
    on the same area is morally awesome?
    Unlike phpng, this is a tactical patch that while changes a lot of code, is
    mostly about "dirty work" than research.
    A hack over a hack remains a hack. With all respects to the authors and
    what they achieved so far.
    Spinning phpng's work as something evil is as ridiculous as it is wrong.
    Who said that?
    Sabotaging it because of it is even worse.
    Excuse me?

    You don't seem to realize what's going on here. It won't delay it, it'll
    greatly slow it down, and given phpng is all about performance - it
    negates

    This is again wrong. It is not slow but a small memory usage increase. It
    is even actually faster with the 64bit patch in many cases (based on
    5.6+patch, phpng+patch coming as soon as I am done with making it portable).
    For the current PHP it yields an 8% memory increase.
    Wrong again. We show 4% increase.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 17, '14 at 10:54a
activeMay 19, '14 at 10:04p
posts13
users6
websitephp.net

People

Translate

site design / logo © 2022 Grokbase