FAQ

[PHP-INTERNALS] RFC: Move phpng to master

Zeev Suraski
Jul 21, 2014 at 7:31 am
All,



As we’re getting closer to release 5.6.0, and given the very high level of
interest in phpng, I think it’s time for us to provide some clarity
regarding what happens post 5.6.0.



Dmitry and I wrote an RFC proposing that we merge phpng into master and
turn it into the basis of the next major version of PHP (name TBD).



The RFC is available at https://wiki.php.net/rfc/phpng



Some supporting links available down below.



Comments welcome!



Zeev







Performance evaluation & evolution of phpng:

https://wiki.php.net/phpng#performance_evaluation



phpng internals:

https://wiki.php.net/phpng-int



Benchmarking PHPNG (benchmark results of phpng vs 5.4, 5.5, 5.6 and hhvm):

http://zsuraski.blogspot.co.il/2014/07/benchmarking-phpng.html
reply

Search Discussions

137 responses

  • Pierre Joye at Jul 21, 2014 at 7:52 am
    hi Zeev,
    On Mon, Jul 21, 2014 at 9:31 AM, Zeev Suraski wrote:
    All,



    As we’re getting closer to release 5.6.0, and given the very high level of
    interest in phpng, I think it’s time for us to provide some clarity
    regarding what happens post 5.6.0.



    Dmitry and I wrote an RFC proposing that we merge phpng into master and
    turn it into the basis of the next major version of PHP (name TBD).



    The RFC is available at https://wiki.php.net/rfc/phpng



    Some supporting links available down below.



    Comments welcome!
    Quoting Dmitry's mail from last week "phpng is an experimental
    branch", as such, I see no appealing reasons to replace master with
    phpng and use phpng as base for the next major version. I am not
    really surprised by this request, despite contradictory comments about
    this exact point in the past few weeks.

    Despite the excellent performance improvements, it is by far not ready
    to be used as base for the next major release, the release we will
    have to maintain for the next decade. There is almost no
    documentation, the APIs are not clean or inconsistent (just came back
    home, will provide details later) but having two separate zpp, same
    area's functions mixing use of zend_char and char (creating hard to
    catch bugs, not always catch-able at compile time f.e.), no (known)
    plan about when the experiments will stop and when or how deep the
    cleanup will be done.

    In other words, I cannot agree to replace master with phpng, not with
    its current state and it is definitively not what I could imagine as a
    base for php-next. A roadmap, undocumented and plan-less development
    (sorry, but stacking up a couple of % performance improvement has
    little to nothing to do with designing php-next) is the best way to
    fail to have what many of our users and developers could expect for
    php-next.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Julien Pauli at Jul 21, 2014 at 8:21 am

    On Mon, Jul 21, 2014 at 9:52 AM, Pierre Joye wrote:
    hi Zeev,
    On Mon, Jul 21, 2014 at 9:31 AM, Zeev Suraski wrote:
    All,



    As we’re getting closer to release 5.6.0, and given the very high level of
    interest in phpng, I think it’s time for us to provide some clarity
    regarding what happens post 5.6.0.



    Dmitry and I wrote an RFC proposing that we merge phpng into master and
    turn it into the basis of the next major version of PHP (name TBD).



    The RFC is available at https://wiki.php.net/rfc/phpng



    Some supporting links available down below.



    Comments welcome!
    Quoting Dmitry's mail from last week "phpng is an experimental
    branch", as such, I see no appealing reasons to replace master with
    phpng and use phpng as base for the next major version. I am not
    really surprised by this request, despite contradictory comments about
    this exact point in the past few weeks.

    Despite the excellent performance improvements, it is by far not ready
    to be used as base for the next major release, the release we will
    have to maintain for the next decade. There is almost no
    documentation, the APIs are not clean or inconsistent (just came back
    home, will provide details later) but having two separate zpp, same
    area's functions mixing use of zend_char and char (creating hard to
    catch bugs, not always catch-able at compile time f.e.), no (known)
    plan about when the experiments will stop and when or how deep the
    cleanup will be done.

    In other words, I cannot agree to replace master with phpng, not with
    its current state and it is definitively not what I could imagine as a
    base for php-next. A roadmap, undocumented and plan-less development
    (sorry, but stacking up a couple of % performance improvement has
    little to nothing to do with designing php-next) is the best way to
    fail to have what many of our users and developers could expect for
    php-next.

    Cheers,
    --
    Pierre
    Hi

    I can only agree here.

    I'd like a clean API. We need to consider PHP-Next jump as an opportunity to
    clean our API and finally have something understandable for a
    newcomer, and documented. That's a move nobody dared to take in the
    last decade, degrading more and more our codebase in term of
    understandability and flexibility. This can't last

    Old features and unused things should be cleaned up.
    Quickly caught, impacting the engine :
    - Resources are a hell, mixed with zend_lists etc... inconsitstent and
    absolutely PITA to develop with.
    - Streams need to be cleaned up and reworked to support full
    asynchronous IOs, which could involve threads, thus engine tied
    - Signals have been worked on starting with 5.4 (AFAIR), but never
    activated by default. I guess the actual implementation lacks a bit
    more reflection to be stable, and to finally propose signal managers
    into userland. ext/pcntl should be somehow merged to core, and this as
    well would involve engine work
    - TSRM need to find love, or to find a better replacement, which would
    involve a big engine work as well
    - ... and so on

    Macro hell should be reworked as inlined functions, and I'd like we
    start supporting C99 as well.

    Performance is a userland point.
    API, doc, and clean things are developers points, and IMO, they are as
    important.

    What about merging OPCache to the branch ?
    This was talked about at PHP5.5 release, has never happened yet, and
    doesn't seem planed. This could have a big impact on the engine
    codebase.

    I just cant believe we won't rework our API , fully and deeply, for PHP-Next.

    Julien
  • Zeev Suraski at Jul 21, 2014 at 8:33 am

    Hi

    We need to consider PHP-Next jump as an opportunity to
    clean our API and finally have something understandable for a newcomer,
    and
    documented. That's a move nobody dared to take in the last decade,
    degrading more and more our codebase in term of understandability and
    flexibility. This can't last
    It's absolutely fine to have separate discussions on cleaning APIs, new
    features and any other changes people think we should do, but it absolutely
    has nothing to do with phpng moving into master. We can take the
    opportunity of a major version to do some cleanups, BUT:

    1. It's independent from the phpng effort and RFC. We should vote on it as
    soon as possible to remove any doubts that do linger in people's minds
    regarding whether at all we're going to use it.
    2. We should set a due date for this version, so that we don't wait
    indefinitely for things to happen. We don't have the luxury of 'sitting' on
    phpng for years, IMHO. This too is an independent question from this RFC.

    I just cant believe we won't rework our API , fully and deeply, for
    PHP-Next.
    You're more than welcome to make such proposals and either write patches or
    rally others to write them. This RFC doesn't preclude any other changes
    happening in PHP.NEXT, it just removes the doubts about this being the basis
    for the next version of PHP.

    Regarding Dmitry saying that phpng is an experimental branch - that was a
    couple of months ago. It evolved, it runs apps in parity with 5.6, and it's
    fine to move it to master right now. The alternative - developing 5.7 on
    master and creating a synchronization hell - sounds like a horrible course
    of action.

    Zeev
  • Sebastian Bergmann at Jul 21, 2014 at 9:13 am

    Am 21.07.2014 10:33, schrieb Zeev Suraski:
    Regarding Dmitry saying that phpng is an experimental branch - that was a
    couple of months ago. It evolved, it runs apps in parity with 5.6, and it's
    fine to move it to master right now. The alternative - developing 5.7 on
    master and creating a synchronization hell - sounds like a horrible course
    of action.
      I was not able to run PHPUnit using PHPNG at all back when it was first
      announced.

      I was able to run PHPUnit 4.3 (master)'s test suite using PHPNG last
      week, btw. Only one test fails (due to a change in the output of
      print_r() for SplObjectStorage IIRC). This tells me that there was a lot
      of progress :-)
  • Matteo Beccati at Jul 21, 2014 at 10:07 am

    On 21/07/2014 11:13, Sebastian Bergmann wrote:
    Am 21.07.2014 10:33, schrieb Zeev Suraski:
    Regarding Dmitry saying that phpng is an experimental branch - that was a
    couple of months ago. It evolved, it runs apps in parity with 5.6, and it's
    fine to move it to master right now. The alternative - developing 5.7 on
    master and creating a synchronization hell - sounds like a horrible course
    of action.
    I was not able to run PHPUnit using PHPNG at all back when it was first
    announced.

    I was able to run PHPUnit 4.3 (master)'s test suite using PHPNG last
    week, btw. Only one test fails (due to a change in the output of
    print_r() for SplObjectStorage IIRC). This tells me that there was a lot
    of progress :-)
    I have temporarily re-enabled the phpng jobs on my CI server to assess
    the current situation.

    I can confirm that just one test is failing with PHPUnit master. It
    seems that print_r is not displaying StdClass properties as it used to:

    https://revive.beccati.com/bamboo/browse/PHP-PHPUN-PHPNG-55/test/case/11800493


    On the other hand Doctrine master can't even run the entire test suite
    due to:

    Fatal error: Call to a member function getConfiguration() on null in
    /home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHPNG/tests/Doctrine/Tests/OrmFunctionalTestCase.php
    on line 482

    (pretty sure it's not a null there: a var_dump before the call tells me
    it's an object)

    https://revive.beccati.com/bamboo/browse/PHP-DOCTR-PHPNG-52/log


    The Revive Adserver test suite fails miserably (86+ out of 274 test
    files), mostly due to errors like:

    /home/atlassian/bamboo/xml-data/build-dir/PHP-SRC3-BUIL/Zend/zend_hash.c(1369)
    : ht=0x29c7aa8 is already destroyed

    and some "Call to a member function" errors on object variables that are
    mysteriously seen as null.

    https://revive.beccati.com/bamboo/browse/REV-LP-PNGP-64

    There's lots of legacy code in there and it has proved to be useful in
    past to catch a few uncommon segmentation faults. I'm pretty sure that
    there are plenty other applications that can't work with phpng as it is now.

    To be honest I don't think we're anywhere near the point where it's safe
    to merge phpng to master.

    Also, one thing that might have been overlooked is that merging phpng to
    master would completely bypass the voting phase on
    https://wiki.php.net/rfc/fast_zpp


    Cheers
    --
    Matteo Beccati

    Development & Consulting - http://www.beccati.com/
  • Zeev Suraski at Jul 21, 2014 at 10:16 am

    -----Original Message-----
    From: Matteo Beccati
    Sent: Monday, July 21, 2014 1:08 PM
    To: int...@...net
    Cc: Sebastian Bergmann
    Subject: Re: [PHP-DEV] RFC: Move phpng to master

    To be honest I don't think we're anywhere near the point where it's safe
    to
    merge phpng to master.
    Why? People aren't supposed to run production or even development code
    initially from master.

    I don't know how many people here were around when PHP 5, 4 and 3 came to
    be - but when you're dealing with a major version with such massive code
    changes, you don't get everything right in day one. It will require a
    community effort - which is exactly what we're trying to achieve here. I
    don't think that community effort will happen if we don't move it to master
    and give developers the needed clarity and motivation to work on this.
    Also, one thing that might have been overlooked is that merging phpng to
    master would completely bypass the voting phase on
    https://wiki.php.net/rfc/fast_zpp
    Our thinking is to use this only for performance sensitive functions that
    actually move the needle, as opposed to using it across the board - which
    was the original thinking behind the fast_zpp API. Fast_zpp for this
    limited set of functions is now a part of phpng; We can decide whether or
    not we revisit the proposal for using fast_zpp more widely, although as I
    said in the past, I'm not too fond of the new macro-based APIs myself. For
    performance sensitive functions that are used a lot, though, I think it
    makes perfect sense.

    Zeev
  • Marco Pivetta at Jul 21, 2014 at 10:24 am
    Hi Zeev,
    On Mon, Jul 21, 2014 at 12:16 PM, Zeev Suraski wrote:

    -----Original Message-----
    From: Matteo Beccati
    Sent: Monday, July 21, 2014 1:08 PM
    To: int...@...net
    Cc: Sebastian Bergmann
    Subject: Re: [PHP-DEV] RFC: Move phpng to master

    To be honest I don't think we're anywhere near the point where it's safe
    to
    merge phpng to master.
    Why? People aren't supposed to run production or even development code
    initially from master.
    I don't know how things are driven here, but I assume that OSS projects
    don't merge stuff into master until tests pass: it's as simple as that.
    That's your blocker right there, regardless of voting or any other
    discussion going on.

    Marco Pivetta

    http://twitter.com/Ocramius

    http://ocramius.github.com/
  • Zeev Suraski at Jul 21, 2014 at 10:30 am
    I don't know how things are driven here, but I assume that OSS projects
    don't merge stuff into master until tests pass: it's as simple as that.

    That's your blocker right there, regardless of voting or any other
    discussion going on.



    There’s a huge difference between a major code changes as we line up for a
    new major version – one that requires widespread testing and community
    support – and the relatively minor changes we’ve had here ever since PHP 5.

    So from my POV at least, that assumption is incorrect.


    Zeev
  • Marco Pivetta at Jul 21, 2014 at 10:36 am

    On Mon, Jul 21, 2014 at 12:30 PM, Zeev Suraski wrote:
    There’s a huge difference between a major code changes as we line up for a
    new major version – one that requires widespread testing and community
    support – and the relatively minor changes we’ve had here ever since PHP 5.

    So from my POV at least, that assumption is incorrect.
    We provide an extensive test suite (for every project) which can be run by
    anyone, and you are getting my feedback for it right now ;-)
    Matteo was also nice to set up a PHPNG environment where D2 tests are run,
    so you can have continuous feedback as well.

    Marco Pivetta

    http://twitter.com/Ocramius

    http://ocramius.github.com/
  • Dmitry Stogov at Jul 21, 2014 at 10:42 am
    Hi Matteo,

    We have very limited forces to test everything. Once we we have bug reports
    we may look into the problems and fix them.

    According to FAST_ZPP part, the commit message and comments in the code
    clearly say that this part may be changed in the future.
    We should vote for it separately and then change or remove it according to
    agreement.

    Thanks. Dmitry.

    On Mon, Jul 21, 2014 at 2:07 PM, Matteo Beccati wrote:
    On 21/07/2014 11:13, Sebastian Bergmann wrote:
    Am 21.07.2014 10:33, schrieb Zeev Suraski:
    Regarding Dmitry saying that phpng is an experimental branch - that was
    a
    couple of months ago. It evolved, it runs apps in parity with 5.6, and
    it's
    fine to move it to master right now. The alternative - developing 5.7
    on
    master and creating a synchronization hell - sounds like a horrible
    course
    of action.
    I was not able to run PHPUnit using PHPNG at all back when it was first
    announced.

    I was able to run PHPUnit 4.3 (master)'s test suite using PHPNG last
    week, btw. Only one test fails (due to a change in the output of
    print_r() for SplObjectStorage IIRC). This tells me that there was a lot
    of progress :-)
    I have temporarily re-enabled the phpng jobs on my CI server to assess
    the current situation.

    I can confirm that just one test is failing with PHPUnit master. It
    seems that print_r is not displaying StdClass properties as it used to:


    https://revive.beccati.com/bamboo/browse/PHP-PHPUN-PHPNG-55/test/case/11800493


    On the other hand Doctrine master can't even run the entire test suite
    due to:

    Fatal error: Call to a member function getConfiguration() on null in

    /home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHPNG/tests/Doctrine/Tests/OrmFunctionalTestCase.php
    on line 482

    (pretty sure it's not a null there: a var_dump before the call tells me
    it's an object)

    https://revive.beccati.com/bamboo/browse/PHP-DOCTR-PHPNG-52/log


    The Revive Adserver test suite fails miserably (86+ out of 274 test
    files), mostly due to errors like:


    /home/atlassian/bamboo/xml-data/build-dir/PHP-SRC3-BUIL/Zend/zend_hash.c(1369)
    : ht=0x29c7aa8 is already destroyed

    and some "Call to a member function" errors on object variables that are
    mysteriously seen as null.

    https://revive.beccati.com/bamboo/browse/REV-LP-PNGP-64

    There's lots of legacy code in there and it has proved to be useful in
    past to catch a few uncommon segmentation faults. I'm pretty sure that
    there are plenty other applications that can't work with phpng as it is
    now.

    To be honest I don't think we're anywhere near the point where it's safe
    to merge phpng to master.

    Also, one thing that might have been overlooked is that merging phpng to
    master would completely bypass the voting phase on
    https://wiki.php.net/rfc/fast_zpp


    Cheers
    --
    Matteo Beccati

    Development & Consulting - http://www.beccati.com/

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Pierre Joye at Jul 21, 2014 at 10:45 am

    On Mon, Jul 21, 2014 at 12:41 PM, Dmitry Stogov wrote:
    Hi Matteo,

    We have very limited forces to test everything. Once we we have bug reports
    we may look into the problems and fix them.

    According to FAST_ZPP part, the commit message and comments in the code
    clearly say that this part may be changed in the future.
    We should vote for it separately and then change or remove it according to
    agreement.
    According to what happened in recent RFCs, rejected because a tiny
    part of the patch did not represent what is actually proposed,
    removing parts must be done before voting then, proposed as separated
    RFCs, at the same time or later.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Matteo Beccati at Jul 21, 2014 at 2:07 pm

    On 21/07/2014 12:41, Dmitry Stogov wrote:
    Hi Matteo,

    We have very limited forces to test everything. Once we we have bug reports
    we may look into the problems and fix them.
    I've been trying to help with testing and reporting on IRC the results.
    I think I've mentioned Doctrine a few times already too (on bugs.php.net
    phpng is missing in the version field).

    What's the best way to report issues, especially if they show up when
    running large test suites and it's not possible to create small
    self-contained snippets?


    Cheers
    --
    Matteo Beccati

    Development & Consulting - http://www.beccati.com/
  • Benjamin Eberlei at Jul 21, 2014 at 2:19 pm

    On Mon, Jul 21, 2014 at 12:41 PM, Dmitry Stogov wrote:

    Hi Matteo,

    We have very limited forces to test everything. Once we we have bug reports
    we may look into the problems and fix them.
    Wouldn't it be super easy to use the HHVM team infrastructure to test a
    version against various PHP projects testsuites? I can't imagine it would
    take longer than a few hours to adjust this to PHPs needs.

    Thanks. Dmitry.

    On Mon, Jul 21, 2014 at 2:07 PM, Matteo Beccati wrote:
    On 21/07/2014 11:13, Sebastian Bergmann wrote:
    Am 21.07.2014 10:33, schrieb Zeev Suraski:
    Regarding Dmitry saying that phpng is an experimental branch - that
    was
    a
    couple of months ago. It evolved, it runs apps in parity with 5.6,
    and
    it's
    fine to move it to master right now. The alternative - developing 5.7
    on
    master and creating a synchronization hell - sounds like a horrible
    course
    of action.
    I was not able to run PHPUnit using PHPNG at all back when it was
    first
    announced.

    I was able to run PHPUnit 4.3 (master)'s test suite using PHPNG last
    week, btw. Only one test fails (due to a change in the output of
    print_r() for SplObjectStorage IIRC). This tells me that there was a
    lot
    of progress :-)
    I have temporarily re-enabled the phpng jobs on my CI server to assess
    the current situation.

    I can confirm that just one test is failing with PHPUnit master. It
    seems that print_r is not displaying StdClass properties as it used to:


    https://revive.beccati.com/bamboo/browse/PHP-PHPUN-PHPNG-55/test/case/11800493

    On the other hand Doctrine master can't even run the entire test suite
    due to:

    Fatal error: Call to a member function getConfiguration() on null in

    /home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHPNG/tests/Doctrine/Tests/OrmFunctionalTestCase.php
    on line 482

    (pretty sure it's not a null there: a var_dump before the call tells me
    it's an object)

    https://revive.beccati.com/bamboo/browse/PHP-DOCTR-PHPNG-52/log


    The Revive Adserver test suite fails miserably (86+ out of 274 test
    files), mostly due to errors like:


    /home/atlassian/bamboo/xml-data/build-dir/PHP-SRC3-BUIL/Zend/zend_hash.c(1369)
    : ht=0x29c7aa8 is already destroyed

    and some "Call to a member function" errors on object variables that are
    mysteriously seen as null.

    https://revive.beccati.com/bamboo/browse/REV-LP-PNGP-64

    There's lots of legacy code in there and it has proved to be useful in
    past to catch a few uncommon segmentation faults. I'm pretty sure that
    there are plenty other applications that can't work with phpng as it is
    now.

    To be honest I don't think we're anywhere near the point where it's safe
    to merge phpng to master.

    Also, one thing that might have been overlooked is that merging phpng to
    master would completely bypass the voting phase on
    https://wiki.php.net/rfc/fast_zpp


    Cheers
    --
    Matteo Beccati

    Development & Consulting - http://www.beccati.com/

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Pierre Joye at Jul 21, 2014 at 2:24 pm

    On Mon, Jul 21, 2014 at 4:19 PM, Benjamin Eberlei wrote:
    On Mon, Jul 21, 2014 at 12:41 PM, Dmitry Stogov wrote:

    Hi Matteo,

    We have very limited forces to test everything. Once we we have bug reports
    we may look into the problems and fix them.
    Wouldn't it be super easy to use the HHVM team infrastructure to test a
    version against various PHP projects testsuites? I can't imagine it would
    take longer than a few hours to adjust this to PHPs needs.
    Exactly, and we do have a good one too. But if nobody reads it or
    nobody cares, we can add as much CI as we want, that won't change
    anything.

    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • JoshyPHP at Jul 21, 2014 at 9:17 am

    On 21/07/2014, Zeev Suraski wrote:

    Regarding Dmitry saying that phpng is an experimental branch - that was a
    couple of months ago. It evolved, it runs apps in parity with 5.6, and
    it's
    fine to move it to master right now.
    Perhaps you could write a summary of what's changed since phpng was
    uncovered a couple of months ago? (besides better performance and
    greater compatibility with existing PHP) And also update the existing
    RFC with the benefits of merging this branch to master, as opposed to
    describing the inconvenience of not merging it.

    I'm sure that would help keep the discussion on topic and grounded in fact.
  • Pierre Joye at Jul 21, 2014 at 10:19 am

    On Mon, Jul 21, 2014 at 10:33 AM, Zeev Suraski wrote:

    It's absolutely fine to have separate discussions on cleaning APIs, new
    features and any other changes people think we should do, but it absolutely
    has nothing to do with phpng moving into master. We can take the
    opportunity of a major version to do some cleanups, BUT:
    It is obviously not only absolutely fine, it is a requirement. It
    should have done before anything else, for obvious reasons.

    1. It's independent from the phpng effort and RFC. We should vote on it as
    soon as possible to remove any doubts that do linger in people's minds
    regarding whether at all we're going to use it.
    If it is independent from phpng then phpng is nothing more than a (set
    of) patches that should be proposed independently and not as a
    replacement for master or as base for php-next.
    2. We should set a due date for this version, so that we don't wait
    indefinitely for things to happen. We don't have the luxury of 'sitting' on
    phpng for years, IMHO. This too is an independent question from this RFC.
    I wonder when you have been while we were talking about what we
    actually like to do and have in php-next. Maybe it was a better
    strategic choice to participate in the various efforts to get a clear,
    well discussed and designed roadmap rather than doing this massive set
    of patches in your corner. And yes, I already said that many times.
    I just cant believe we won't rework our API , fully and deeply, for
    PHP-Next.
    You're more than welcome to make such proposals and either write patches or
    rally others to write them. This RFC doesn't preclude any other changes
    happening in PHP.NEXT, it just removes the doubts about this being the basis
    for the next version of PHP.
    As a matter of facts, and despite your (team) numerous posts saying
    that you had no plan to do what you are proposing here, the efforts
    for php-next has simply being stopped to avoid the pain that was the
    64bit RFC because of phpng. A RFC that you totally agreed to have in
    next as it was earlier this year after having rejecting it for 5.x.
    Regarding Dmitry saying that phpng is an experimental branch - that was a
    couple of months ago.
    That was last week or at the end of the previous week. Amazingly
    enough, at the same time you were saying that phpng was pretty stable
    and no more huge changes will happen, many huge changes reached this
    branch, and these changes were not bugs fixes. It tells me a lot about
    the visibility you have on phpng. I do not mean to offend anyone here
    but for what I see here is what we had with opcache, power 20. I do
    not want to see that for php-next, or we can just begin to vote for
    what will be the next major version once we borked 6 and 7.
    It evolved, it runs apps in parity with 5.6, and it's
    fine to move it to master right now. The alternative - developing 5.7 on
    master and creating a synchronization hell - sounds like a horrible course
    of action.
    Welcome to the world you created for us since you rejected a 200%
    stable branch and then killing it by introducing an experimental one,
    with a clear goal, from the very beginning, to replace master for the
    next major version. This world is not the one I want or wish for the
    PHP core.

    Now, enough bashing.

    What I wish to even consider reviewing or discussing phpng any further:

    - clear documentation of the changes and migration plans
    - clear roadmap of upcoming changes, even work in progress
    - how open you are to changes (cleanup, APIs consistency
    "improvements",etc.) in phpng before it is merged, no matter how
    - integration of existing patches, blocked now since months by phpng,
    and how you plan to support us to merge them in phpng, if it ever
    happens.
    - actual discussions about what we want for php-next, as performance
    is only very tiny part of the work for php-next


    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Dmitry Stogov at Jul 21, 2014 at 9:28 am
    Hi Julien,

    Hi

    I can only agree here.

    I'd like a clean API. We need to consider PHP-Next jump as an opportunity
    to
    clean our API and finally have something understandable for a
    newcomer, and documented. That's a move nobody dared to take in the
    last decade, degrading more and more our codebase in term of
    understandability and flexibility. This can't last
    I'm more than agree about internal cleanup.
    phpng benchmark results proved that we take the right direction and now we
    implemented most the ideas we had.
    Note that we tried not to change PHP behaviour in any way.
    Now it's a good time to start the cleanup work.

    Old features and unused things should be cleaned up.
    Quickly caught, impacting the engine :
    - Resources are a hell, mixed with zend_lists etc... inconsitstent and
    absolutely PITA to develop with.
    - Streams need to be cleaned up and reworked to support full
    asynchronous IOs, which could involve threads, thus engine tied
    - Signals have been worked on starting with 5.4 (AFAIR), but never
    activated by default. I guess the actual implementation lacks a bit
    more reflection to be stable, and to finally propose signal managers
    into userland. ext/pcntl should be somehow merged to core, and this as
    well would involve engine work
    - TSRM need to find love, or to find a better replacement, which would
    involve a big engine work as well
    - ... and so on
    Some of the topics above are really big... :)

    Macro hell should be reworked as inlined functions, and I'd like we
    start supporting C99 as well.

    Performance is a userland point.
    API, doc, and clean things are developers points, and IMO, they are as
    important.

    What about merging OPCache to the branch ?
    This was talked about at PHP5.5 release, has never happened yet, and
    doesn't seem planed. This could have a big impact on the engine
    codebase.
    What do you mean? isn't it already there.
    I'm also going to remove opcache code for old PHP versions in php-next.

    I just cant believe we won't rework our API , fully and deeply, for
    PHP-Next.
    You and others are welcome. Once we merge phpng into master, we all may
    cooperate better.

    Thanks. Dmitry.

    Julien

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Julien Pauli at Jul 21, 2014 at 10:25 am

    On Mon, Jul 21, 2014 at 11:27 AM, Dmitry Stogov wrote:
    Hi Julien,
    Hi

    I can only agree here.

    I'd like a clean API. We need to consider PHP-Next jump as an opportunity
    to
    clean our API and finally have something understandable for a
    newcomer, and documented. That's a move nobody dared to take in the
    last decade, degrading more and more our codebase in term of
    understandability and flexibility. This can't last

    I'm more than agree about internal cleanup.
    phpng benchmark results proved that we take the right direction and now we
    implemented most the ideas we had.
    Note that we tried not to change PHP behaviour in any way.
    Now it's a good time to start the cleanup work.
    Not changing behavior is nice and very hard work to do, so congrats on that one.

    If cleaning the API receives "no-go" because the cleanups would
    involve swaping some parameters in functions, or turning macros to
    inline functions , which drops some little percentage in performance
    on some rare compilers, then there will be a problem to me.

    We need a trade-off here. We can't leave unreadable code in, should
    this code be written in a specific way for performances. We can afford
    a little 1% or 2 IMO.
    Old features and unused things should be cleaned up.
    Quickly caught, impacting the engine :
    - Resources are a hell, mixed with zend_lists etc... inconsitstent and
    absolutely PITA to develop with.
    - Streams need to be cleaned up and reworked to support full
    asynchronous IOs, which could involve threads, thus engine tied
    - Signals have been worked on starting with 5.4 (AFAIR), but never
    activated by default. I guess the actual implementation lacks a bit
    more reflection to be stable, and to finally propose signal managers
    into userland. ext/pcntl should be somehow merged to core, and this as
    well would involve engine work
    - TSRM need to find love, or to find a better replacement, which would
    involve a big engine work as well
    - ... and so on

    Some of the topics above are really big... :)

    Macro hell should be reworked as inlined functions, and I'd like we
    start supporting C99 as well.

    Performance is a userland point.
    API, doc, and clean things are developers points, and IMO, they are as
    important.

    What about merging OPCache to the branch ?
    This was talked about at PHP5.5 release, has never happened yet, and
    doesn't seem planed. This could have a big impact on the engine
    codebase.

    What do you mean? isn't it already there.
    I'm also going to remove opcache code for old PHP versions in php-next.
    I was talking about merging the code bases.
    For example, shared memory model from OPCache could be merged into
    Zend/ and expose an API one could reuse in extensions needing SHM.
    Also, accelerator's code could be merged into Zend/zend_execute and Zend/ZendVM

    Julien
  • Dmitry Stogov at Jul 21, 2014 at 10:50 am

    On Mon, Jul 21, 2014 at 2:24 PM, Julien Pauli wrote:
    On Mon, Jul 21, 2014 at 11:27 AM, Dmitry Stogov wrote:
    Hi Julien,
    Hi

    I can only agree here.

    I'd like a clean API. We need to consider PHP-Next jump as an
    opportunity
    to
    clean our API and finally have something understandable for a
    newcomer, and documented. That's a move nobody dared to take in the
    last decade, degrading more and more our codebase in term of
    understandability and flexibility. This can't last

    I'm more than agree about internal cleanup.
    phpng benchmark results proved that we take the right direction and now we
    implemented most the ideas we had.
    Note that we tried not to change PHP behaviour in any way.
    Now it's a good time to start the cleanup work.
    Not changing behavior is nice and very hard work to do, so congrats on
    that one.

    If cleaning the API receives "no-go" because the cleanups would
    involve swaping some parameters in functions, or turning macros to
    inline functions , which drops some little percentage in performance
    on some rare compilers, then there will be a problem to me.

    We need a trade-off here. We can't leave unreadable code in, should
    this code be written in a specific way for performances. We can afford
    a little 1% or 2 IMO.
    1-2% is not a huge step back :)
    but in case of few such steps we may discard a lot.

    Old features and unused things should be cleaned up.
    Quickly caught, impacting the engine :
    - Resources are a hell, mixed with zend_lists etc... inconsitstent and
    absolutely PITA to develop with.
    - Streams need to be cleaned up and reworked to support full
    asynchronous IOs, which could involve threads, thus engine tied
    - Signals have been worked on starting with 5.4 (AFAIR), but never
    activated by default. I guess the actual implementation lacks a bit
    more reflection to be stable, and to finally propose signal managers
    into userland. ext/pcntl should be somehow merged to core, and this as
    well would involve engine work
    - TSRM need to find love, or to find a better replacement, which would
    involve a big engine work as well
    - ... and so on

    Some of the topics above are really big... :)

    Macro hell should be reworked as inlined functions, and I'd like we
    start supporting C99 as well.

    Performance is a userland point.
    API, doc, and clean things are developers points, and IMO, they are as
    important.

    What about merging OPCache to the branch ?
    This was talked about at PHP5.5 release, has never happened yet, and
    doesn't seem planed. This could have a big impact on the engine
    codebase.

    What do you mean? isn't it already there.
    I'm also going to remove opcache code for old PHP versions in php-next.
    I was talking about merging the code bases.
    For example, shared memory model from OPCache could be merged into
    Zend/ and expose an API one could reuse in extensions needing SHM.
    Also, accelerator's code could be merged into Zend/zend_execute and
    Zend/ZendVM
    We thought about it many time, but didn't have time to do it.

    Thanks. Dmitry.

    Julien
  • Pierre Joye at Jul 21, 2014 at 10:56 am

    On Mon, Jul 21, 2014 at 12:50 PM, Dmitry Stogov wrote:

    We thought about it many time, but didn't have time to do it.
    cleanup makes code bases smaller, more maintainable, easier to change.
    The time spent to port dead parts of PHP should have been better
    spent. It is too late to do that :)

    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Xinchen Hui at Jul 21, 2014 at 3:23 pm
    Hey:
    在 2014年7月21日,18:56,Pierre Joye <pie...@...com> 写道:
    On Mon, Jul 21, 2014 at 12:50 PM, Dmitry Stogov wrote:

    We thought about it many time, but didn't have time to do it.
    cleanup makes code bases smaller, more maintainable, easier to change.
    The time spent to port dead parts of PHP should have been better
    spent. It is too late to do that :)
    I don't know what kind of cleanup are you talking? I have spent
    months to do that, convert exts, cleanup dead codes, refactor ugly
    hacks

    If that still not enough, I think we should merge phpng to master
    ASAP, then people can help me to do such things.

    Thanks
    --
    Pierre

    @pierrejoye | http://www.libgd.org

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Derick Rethans at Jul 21, 2014 at 10:41 am

    On Mon, 21 Jul 2014, Dmitry Stogov wrote:

    I can only agree here.

    I'd like a clean API. We need to consider PHP-Next jump as an
    opportunity to clean our API and finally have something
    understandable for a newcomer, and documented. That's a move nobody
    dared to take in the last decade, degrading more and more our
    codebase in term of understandability and flexibility. This can't
    last
    I'm more than agree about internal cleanup. phpng benchmark results
    proved that we take the right direction and now we implemented most
    the ideas we had. Note that we tried not to change PHP behaviour in
    any way. Now it's a good time to start the cleanup work.
    Actually, I think that should be done after merging / changing it to
    master. Right now, the phpng vs master branch differences are ... rather
    large. It'd be good to do additional cleanup in smaller chunks later on
    as it makes it a lot easier to review those changes.

    cheers,
    Derick
  • Pierre Joye at Jul 21, 2014 at 10:44 am

    On Mon, Jul 21, 2014 at 12:41 PM, Derick Rethans wrote:
    On Mon, 21 Jul 2014, Dmitry Stogov wrote:

    I can only agree here.

    I'd like a clean API. We need to consider PHP-Next jump as an
    opportunity to clean our API and finally have something
    understandable for a newcomer, and documented. That's a move nobody
    dared to take in the last decade, degrading more and more our
    codebase in term of understandability and flexibility. This can't
    last
    I'm more than agree about internal cleanup. phpng benchmark results
    proved that we take the right direction and now we implemented most
    the ideas we had. Note that we tried not to change PHP behaviour in
    any way. Now it's a good time to start the cleanup work.
    Actually, I think that should be done after merging / changing it to
    master. Right now, the phpng vs master branch differences are ... rather
    large. It'd be good to do additional cleanup in smaller chunks later on
    as it makes it a lot easier to review those changes.
    Review and changes in the feature(s) branch, then propose when ready.
    This is also why I asked to do so in the 1st days when phpng was
    proposed: Stop adding new changes, cleanup, stabilize, propose,
    continue the work. They refused it and now we should do it in the most
    ugly way? Merging into master or even worst replace master with
    something we have no idea about? Seriously?


    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Michael Wallner at Jul 21, 2014 at 9:37 am

    On 21 Jul 2014 10:21, "Julien Pauli" wrote:
    On Mon, Jul 21, 2014 at 9:52 AM, Pierre Joye wrote:
    hi Zeev,
    On Mon, Jul 21, 2014 at 9:31 AM, Zeev Suraski wrote:
    All,



    As we’re getting closer to release 5.6.0, and given the very high
    level of
    interest in phpng, I think it’s time for us to provide some clarity
    regarding what happens post 5.6.0.



    Dmitry and I wrote an RFC proposing that we merge phpng into master and
    turn it into the basis of the next major version of PHP (name TBD).



    The RFC is available at https://wiki.php.net/rfc/phpng



    Some supporting links available down below.



    Comments welcome!
    Quoting Dmitry's mail from last week "phpng is an experimental
    branch", as such, I see no appealing reasons to replace master with
    phpng and use phpng as base for the next major version. I am not
    really surprised by this request, despite contradictory comments about
    this exact point in the past few weeks.

    Despite the excellent performance improvements, it is by far not ready
    to be used as base for the next major release, the release we will
    have to maintain for the next decade. There is almost no
    documentation, the APIs are not clean or inconsistent (just came back
    home, will provide details later) but having two separate zpp, same
    area's functions mixing use of zend_char and char (creating hard to
    catch bugs, not always catch-able at compile time f.e.), no (known)
    plan about when the experiments will stop and when or how deep the
    cleanup will be done.

    In other words, I cannot agree to replace master with phpng, not with
    its current state and it is definitively not what I could imagine as a
    base for php-next. A roadmap, undocumented and plan-less development
    (sorry, but stacking up a couple of % performance improvement has
    little to nothing to do with designing php-next) is the best way to
    fail to have what many of our users and developers could expect for
    php-next.

    Cheers,
    --
    Pierre
    Hi

    I can only agree here.

    I'd like a clean API. We need to consider PHP-Next jump as an opportunity to
    clean our API and finally have something understandable for a
    newcomer, and documented. That's a move nobody dared to take in the
    last decade, degrading more and more our codebase in term of
    understandability and flexibility. This can't last

    Old features and unused things should be cleaned up.
    Quickly caught, impacting the engine :
    - Resources are a hell, mixed with zend_lists etc... inconsitstent and
    absolutely PITA to develop with.
    - Streams need to be cleaned up and reworked to support full
    asynchronous IOs, which could involve threads, thus engine tied
    - Signals have been worked on starting with 5.4 (AFAIR), but never
    activated by default. I guess the actual implementation lacks a bit
    more reflection to be stable, and to finally propose signal managers
    into userland. ext/pcntl should be somehow merged to core, and this as
    well would involve engine work
    - TSRM need to find love, or to find a better replacement, which would
    involve a big engine work as well
    - ... and so on

    Macro hell should be reworked as inlined functions, and I'd like we
    start supporting C99 as well.

    Performance is a userland point.
    API, doc, and clean things are developers points, and IMO, they are as
    important.

    What about merging OPCache to the branch ?
    This was talked about at PHP5.5 release, has never happened yet, and
    doesn't seem planed. This could have a big impact on the engine
    codebase.

    I just cant believe we won't rework our API , fully and deeply, for
    PHP-Next.

    I don't think that a cleanup is nearly as important as php-ng is as we
    stand currently.

    The will be no mercy from the competition.

    We can start reworking the API when it hit master.
  • Pierre Joye at Jul 21, 2014 at 10:22 am
    On Mon, Jul 21, 2014 at 11:37 AM, Michael Wallner wrote:
    >
    I don't think that a cleanup is nearly as important as php-ng is as we stand
    currently.

    The will be no mercy from the competition.

    We can start reworking the API when it hit master.
    Cleanup reduces the work, not increase it. Cleanup eases testing,
    review and maintenance. I am sorry but I totally fail to understand
    why it is not the absolute top goal for next.


    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • David Soria Parra at Jul 22, 2014 at 5:08 am

    On 2014-07-21, Michael Wallner wrote:
    --001a11345984e013cd04feb0d9a1
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: quoted-printable

    On 21 Jul 2014 10:21, "Julien Pauli" wrote:
    PHP-Next.

    I don't think that a cleanup is nearly as important as php-ng is as we
    stand currently.

    The will be no mercy from the competition.

    We can start reworking the API when it hit master.

    --001a11345984e013cd04feb0d9a1--
    I want to remind that the last attempt of PHP 6 died because it was mostly
    unmaintained as "master" for a long time and we continued to postpone
    it. We should try to not again make a "big move" but take "babysteps"
    and focus on phpng and 64bit as the major features and not maintain a
    branch while we are doing 5.7. This will undoubtful lead to a similar
    "abundance" of the master branch as we just don't have the ressources
    to maintain more branches (a point already made when we discussed the
    release plan).

    I think we should consider steps to make phpng the major development
    branch within the year and if stabelizing it within the year possible,
    make it the next release.
  • Yasuo Ohgaki at Jul 22, 2014 at 5:21 am
    Hi David,
    On Tue, Jul 22, 2014 at 2:08 PM, David Soria Parra wrote:
    On 2014-07-21, Michael Wallner wrote:
    --001a11345984e013cd04feb0d9a1
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: quoted-printable

    On 21 Jul 2014 10:21, "Julien Pauli" wrote:
    PHP-Next.

    I don't think that a cleanup is nearly as important as php-ng is as we
    stand currently.

    The will be no mercy from the competition.

    We can start reworking the API when it hit master.

    --001a11345984e013cd04feb0d9a1--
    I want to remind that the last attempt of PHP 6 died because it was mostly
    unmaintained as "master" for a long time and we continued to postpone
    it. We should try to not again make a "big move" but take "babysteps"
    and focus on phpng and 64bit as the major features and not maintain a
    branch while we are doing 5.7. This will undoubtful lead to a similar
    "abundance" of the master branch as we just don't have the ressources
    to maintain more branches (a point already made when we discussed the
    release plan).

    I think we should consider steps to make phpng the major development
    branch within the year and if stabelizing it within the year possible,
    make it the next release.
    Even if we have PHP-5.7 branch, we have merge up policy. Therefore,
    any new feature will end up with master, I suppose. If a new feature is
    only available to PHP-5.7 branch, it's a merge bug, isn't it?

    Regards,

    --
    Yasuo Ohgaki
    yoh...@...net
  • David Soria Parra at Jul 22, 2014 at 5:42 am

    Am 7/21/14, 10:21 PM, schrieb Yasuo Ohgaki:


    Even if we have PHP-5.7 branch, we have merge up policy. Therefore,
    any new feature will end up with master, I suppose. If a new feature is
    only available to PHP-5.7 branch, it's a merge bug, isn't it?

    Regards,
    We had this policy before and it didn't help us. The problem is
    maintiaining all the branches and keeping people interested in the next
    branch because people tend to focus on the currently release branch.
    When we decided upon the release RFC we talked a lot about the overhead
    of maintaing multiple branches and tried to reduce the amount of
    branches. In particular with API changes it becomes tidious if we try to
    maintain a feature across branches and that implicit divergence has to
    be resolved better sooner or later, or otherwise it would be just like
    the old php6 again.

    David
  • Yasuo Ohgaki at Jul 22, 2014 at 7:01 am
    Hi David,
    On Tue, Jul 22, 2014 at 2:42 PM, David Soria Parra wrote:


    Even if we have PHP-5.7 branch, we have merge up policy. Therefore,
    any new feature will end up with master, I suppose. If a new feature is
    only available to PHP-5.7 branch, it's a merge bug, isn't it?

    Regards,
    We had this policy before and it didn't help us. The problem is
    maintiaining all the branches and keeping people interested in the next
    branch because people tend to focus on the currently release branch.
    When we decided upon the release RFC we talked a lot about the overhead
    of maintaing multiple branches and tried to reduce the amount of
    branches. In particular with API changes it becomes tidious if we try to
    maintain a feature across branches and that implicit divergence has to
    be resolved better sooner or later, or otherwise it would be just like
    the old php6 again.

    I can understand your concern. We have git now and git can easily spot what
    and who haven't merged required changes to master. Working with multiple
    branches and merge is much easier with git also. I think this time it will
    work,
    hopefully.

    My concern is development time. It's too short. We only have about half of
    a year to feature freeze. More than a year would be appropriate for a major
    version up, IMHO. Long alpha/beta period is good for users also.

    Having PHP-5.7 is not a mandatory, but I would like to have it.

    Regards,

    --
    Yasuo Ohgaki
    yoh...@...net
  • Yasuo Ohgaki at Jul 21, 2014 at 9:32 am
    Hi Zeev,
    On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski wrote:

    As we’re getting closer to release 5.6.0, and given the very high level of
    interest in phpng, I think it’s time for us to provide some clarity
    regarding what happens post 5.6.0.
    Are you willing to have 5.7 branch?
    It gives us more time to develop/cleanup/test. It's especially important for
    3rd party module developers.

    Regards,

    --
    Yasuo Ohgaki
    yoh...@...net
  • Zeev Suraski at Jul 21, 2014 at 10:18 am
    *From:* yoh...@...com *On Behalf Of *Yasuo
    Ohgaki
    *Sent:* Monday, July 21, 2014 12:32 PM
    *To:* Zeev Suraski
    *Cc:* PHP internals
    *Subject:* Re: [PHP-DEV] RFC: Move phpng to master



    Hi Zeev,



    On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski wrote:

    As we’re getting closer to release 5.6.0, and given the very high level of
    interest in phpng, I think it’s time for us to provide some clarity
    regarding what happens post 5.6.0.



    Are you willing to have 5.7 branch?

    It gives us more time to develop/cleanup/test. It's especially important for

    3rd party module developers.

    Can you explain a bit more what you mean by that? I generally don’t think
    we should invest in another feature release before this next phpng-based
    major version (that’s my personal thinking). It’ll spread our limited
    resources too thin; But maybe I didn’t quite understand what you had in
    mind for putting in the 5.7 branch.



    Zeev
  • Ferenc Kovacs at Jul 21, 2014 at 10:24 am

    On Mon, Jul 21, 2014 at 12:18 PM, Zeev Suraski wrote:

    *From:* yoh...@...com *On Behalf Of *Yasuo
    Ohgaki
    *Sent:* Monday, July 21, 2014 12:32 PM
    *To:* Zeev Suraski
    *Cc:* PHP internals
    *Subject:* Re: [PHP-DEV] RFC: Move phpng to master



    Hi Zeev,



    On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski wrote:

    As we’re getting closer to release 5.6.0, and given the very high level of
    interest in phpng, I think it’s time for us to provide some clarity
    regarding what happens post 5.6.0.



    Are you willing to have 5.7 branch?

    It gives us more time to develop/cleanup/test. It's especially important
    for

    3rd party module developers.

    Can you explain a bit more what you mean by that? I generally don’t think
    we should invest in another feature release before this next phpng-based
    major version (that’s my personal thinking). It’ll spread our limited
    resources too thin; But maybe I didn’t quite understand what you had in
    mind for putting in the 5.7 branch.



    Zeev
    He just asks if we will have a 5.7 release while working on the next major
    in master.
    I don't think that we can release the php-next under a years, so I think
    that an 5.7 could be warranted (to keep up with our roadmap), but depends
    on wether or not we have enough new (BC-safe) features.


    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Pierre Joye at Jul 21, 2014 at 10:31 am

    On Mon, Jul 21, 2014 at 12:24 PM, Ferenc Kovacs wrote:
    He just asks if we will have a 5.7 release while working on the next major
    in master.
    I don't think that we can release the php-next under a years, so I think
    that an 5.7 could be warranted (to keep up with our roadmap), but depends
    on wether or not we have enough new (BC-safe) features.
    Clearly yes, for two reasons:

    - we do one x.y+1 every year
    - php-next will take 2-3 years, ideally (while I have doubts when I
    see what is going on now)

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Zeev Suraski at Jul 21, 2014 at 10:31 am
    He just asks if we will have a 5.7 release while working on the next major
    in master.

    I don't think that we can release the php-next under a years, so I think
    that an 5.7 could be warranted (to keep up with our roadmap), but depends
    on wether or not we have enough new (BC-safe) features.

    I don’t see a reason of why we can’t have this major version ready by or
    even sooner than the current yearly rhythm we have. In fact, if we do aim
    to work in parallel on both 5.7 and .NEXT – we’re likely to needlessly
    delay .NEXT…



    Zeev
  • Pierre Joye at Jul 21, 2014 at 10:41 am

    On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski wrote:
    He just asks if we will have a 5.7 release while working on the next major
    in master.

    I don't think that we can release the php-next under a years, so I think
    that an 5.7 could be warranted (to keep up with our roadmap), but depends
    on wether or not we have enough new (BC-safe) features.

    I don’t see a reason of why we can’t have this major version ready by or
    even sooner than the current yearly rhythm we have. In fact, if we do aim
    to work in parallel on both 5.7 and .NEXT – we’re likely to needlessly
    delay .NEXT…
    Please, Zeev, please. You are again doing a major time and planning
    estimation mistake, which will affect all of us.

    It is impossible to get php-next ready by next year, simply
    impossible. Even if all we will have is phpng, we won't make it.

    And really, I rather prefer to do not any php-next now if your only
    plans are in phpng.

    And as of getting stable before merging, I totally agree with Marco
    and you did too when we were talking about the 64bit RFC, which is by
    an order of magnitude much smaller and complex than phpng.

    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Ferenc Kovacs at Jul 21, 2014 at 11:01 am

    On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski wrote:

    He just asks if we will have a 5.7 release while working on the next major
    in master.

    I don't think that we can release the php-next under a years, so I think
    that an 5.7 could be warranted (to keep up with our roadmap), but depends
    on wether or not we have enough new (BC-safe) features.

    I don’t see a reason of why we can’t have this major version ready by or
    even sooner than the current yearly rhythm we have. In fact, if we do aim
    to work in parallel on both 5.7 and .NEXT – we’re likely to needlessly
    delay .NEXT…



    Zeev

    because there is so much stuff which we want to do in the next major
    version, but we can't even start because there is no stable base to target
    the other php-next features.
    based on the history of php versions, any feature which misses php-next
    will have to wait for the next decade, so I don't think that we should rush
    it (to meet our yearly release cycle defined in
    https://wiki.php.net/rfc/releaseprocess).

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Pierre Joye at Jul 21, 2014 at 11:10 am

    On Mon, Jul 21, 2014 at 1:01 PM, Ferenc Kovacs wrote:
    On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski wrote:



    He just asks if we will have a 5.7 release while working on the next major
    in master.

    I don't think that we can release the php-next under a years, so I think
    that an 5.7 could be warranted (to keep up with our roadmap), but depends
    on wether or not we have enough new (BC-safe) features.

    I don’t see a reason of why we can’t have this major version ready by or
    even sooner than the current yearly rhythm we have. In fact, if we do aim
    to work in parallel on both 5.7 and .NEXT – we’re likely to needlessly
    delay .NEXT…



    Zeev

    because there is so much stuff which we want to do in the next major
    version, but we can't even start because there is no stable base to target
    the other php-next features.
    based on the history of php versions, any feature which misses php-next
    will have to wait for the next decade, so I don't think that we should rush
    it (to meet our yearly release cycle defined in
    https://wiki.php.net/rfc/releaseprocess).
    Exactly.

    And https://wiki.php.net/ideas/php6 and the related discussions (where
    @Zend and phpng's team were totally absent, go figure).

    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Xinchen Hui at Jul 21, 2014 at 3:28 pm

    Hey:

    在 2014年7月21日,19:02,Ferenc Kovacs <tyr...@...com> 写道:
    On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski wrote:



    He just asks if we will have a 5.7 release while working on the next major
    in master.

    I don't think that we can release the php-next under a years, so I think
    that an 5.7 could be warranted (to keep up with our roadmap), but depends
    on wether or not we have enough new (BC-safe) features.

    I don’t see a reason of why we can’t have this major version ready by or
    even sooner than the current yearly rhythm we have. In fact, if we do aim
    to work in parallel on both 5.7 and .NEXT � we’re likely to needlessly
    delay .NEXT…



    Zeev
    because there is so much stuff which we want to do in the next major
    version, but we can't even start because there is no stable base to target
    the other php-next features.
    What they are? Please come with RFC and Patches.

    Or you suggest we stop the current work to waiting them come their self?

    Thanks
    based on the history of php versions, any feature which misses php-next
    will have to wait for the next decade, so I don't think that we should rush
    it (to meet our yearly release cycle defined in
    https://wiki.php.net/rfc/releaseprocess).

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Pierre Joye at Jul 21, 2014 at 4:03 pm

    On Mon, Jul 21, 2014 at 5:36 PM, Xinchen Hui wrote:

    发自我的 iPad

    在 2014年7月21日,23:30,Pierre Joye <pie...@...com> 写道:

    On Jul 21, 2014 5:28 PM, "Xinchen Hui" wrote:

    Or you suggest we stop the current work to waiting them come their self?
    This is exactly what you have done. So what?

    But no, talking for me (and a couple of other), I have listed what I would
    like to see before I even consider something else than -1.

    With all respects, I think you are too strict on phpng
    I am not strict but I am realistic, to avoid a total failure with php-next.
    We all hope php to get better, for now I really care about performance
    Right, we all care about php. The question is more about how we care
    about its future and how to get everyone involved and get PHP cleaner,
    better and easier to maintain.
    We are loosing users who switch to hhvm for performance. Phpng will change
    the current embarrasse situation to us
    That's not what I see but for very few users. Visibility, cleaner (or
    less ugly) code base, better communication with the developers, etc.
    are more the points why some moves to hhvm. Some features we rejected
    in the past (strict hinting for method/function signature f.e., hack)
    are other reasons mentioned very often.

    Also keep in mind that I do love the performance improvements brought
    by phpng. It is really awesome. And again, thanks you guys for this
    effort.

    However it is critical, I repeat, critical, to keep other goals in
    mind for php-next. You forgot them for the last six months but it is
    too late. However if things go like Zend plans, it will be too late,
    and we will fail, miserably.

    I also talked to many very large PHP users in the last two months. As
    they all care about performance, it is not really their issue right
    now with php. One reason is that PHP rarely causes actual bottlenecks
    in their apps. But they have other worries, one of them is the code
    quality of the PHP core, which is by far not as good as it should be
    for the leading web programming language. And they expect the next
    major version to fix that. Not only to be more confident about the PHP
    implementation but also to ease contributions or extensions
    implementations. PHPNG solves none of these issues, in contrary.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Ferenc Kovacs at Jul 21, 2014 at 4:10 pm

    On Mon, Jul 21, 2014 at 5:28 PM, Xinchen Hui wrote:

    Hey:
    在 2014年7月21日,19:02,Ferenc Kovacs <tyr...@...com> 写道:
    On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski wrote:



    He just asks if we will have a 5.7 release while working on the next
    major
    in master.

    I don't think that we can release the php-next under a years, so I think
    that an 5.7 could be warranted (to keep up with our roadmap), but
    depends
    on wether or not we have enough new (BC-safe) features.

    I don’t see a reason of why we can’t have this major version ready by or
    even sooner than the current yearly rhythm we have. In fact, if we do
    aim
    to work in parallel on both 5.7 and .NEXT � we’re likely to needlessly
    delay .NEXT…



    Zeev
    because there is so much stuff which we want to do in the next major
    version, but we can't even start because there is no stable base to target
    the other php-next features.
    What they are? Please come with RFC and Patches.
    https://wiki.php.net/rfc/uniform_variable_syntax
    https://wiki.php.net/rfc/size_t_and_int64_next

    Or you suggest we stop the current work to waiting them come their self?
    I'm saying that we should resolve the current situation where people can't
    work on stuff which would target php-next, because it is still a moving
    target.
    I'm saying that it is nice that you(the phpng main devs) are confident that
    you can stabilize your changes so making a php-next release in less than a
    year, but other people have other ideas which can only happen in a major
    version, and you shouldn't rush an early release which would mean that the
    next window of opportunity for major refactor is in the next decade.
    I'm saying that it is pretty unfortunate that we have to decide to between
    reviewing/accepting a huuuuuuuge chunk of changes or rejecting a
    significant performance boost and some api cleanup.
    I'm saying that we should stop pushing our own agendas, and figure out the
    best possible solution for the current situation, so that we can go forward
    with the development with the normal workflow, where everybody is on the
    same page, controversial changes are done through RFCs and we don't block
    each other from the work.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Xinchen Hui at Jul 22, 2014 at 1:42 am
    Hey:

          I really don't like arguing in english, so this will be my last
    reply in this thread.
    On Tue, Jul 22, 2014 at 12:10 AM, Ferenc Kovacs wrote:


    On Mon, Jul 21, 2014 at 5:28 PM, Xinchen Hui wrote:

    Hey:
    在 2014年7月21日,19:02,Ferenc Kovacs <tyr...@...com> 写道:
    On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski wrote:



    He just asks if we will have a 5.7 release while working on the next
    major
    in master.

    I don't think that we can release the php-next under a years, so I
    think
    that an 5.7 could be warranted (to keep up with our roadmap), but
    depends
    on wether or not we have enough new (BC-safe) features.

    I don’t see a reason of why we can’t have this major version ready by
    or
    even sooner than the current yearly rhythm we have. In fact, if we do
    aim
    to work in parallel on both 5.7 and .NEXT � we’re likely to needlessly
    delay .NEXT…



    Zeev
    because there is so much stuff which we want to do in the next major
    version, but we can't even start because there is no stable base to
    target
    the other php-next features.
    What they are? Please come with RFC and Patches.

    https://wiki.php.net/rfc/uniform_variable_syntax
    https://wiki.php.net/rfc/size_t_and_int64_next
    aren't they discussed and voted? what do you mean by we can't even
    start in previous comment?
    Or you suggest we stop the current work to waiting them come their self?

    I'm saying that we should resolve the current situation where people can't
    work on stuff which would target php-next, because it is still a moving
    target.
    why Nikita could work on it? why me can work on it?
    I'm saying that it is nice that you(the phpng main devs) are confident that
    you can stabilize your changes so making a php-next release in less than a
    year, but other people have other ideas which can only happen in a major
    version, and you shouldn't rush an early release which would mean that the
    next window of opportunity for major refactor is in the next decade.
    I am not sure about you attitude here, from these words, seems you
    agree to merge phpng to master asap, then people can start work on it?
    I'm saying that it is pretty unfortunate that we have to decide to between
    reviewing/accepting a huuuuuuuge chunk of changes or rejecting a significant
    performance boost and some api cleanup.
    we shouldn't, at least most people here shouldn't, only the guys who
    need to maintain them should.
    I'm saying that we should stop pushing our own agendas, and figure out the
    best possible solution for the current situation, so that we can go forward
    with the development with the normal workflow, where everybody is on the
    same page, controversial changes are done through RFCs and we don't block
    each other from the work.
    you know what? I really don't like "we should; we must", they means nothing..

    I have spent lots of my time to work on PHP/PHPNG, more than 80 hours
    per month.

    I treat it like a regular work, dmitry spends more than me(8 hours per day).

    you ask me to stop to wait somebody who even can not work hours a month here?

    with all my respects: I really upset by people who always told you,
    hey man, don't be rush...

    because I am rushing, I have be rushing for months to make the work done..

    last of all : "all above is my personal comments, has nothing to do
    with Zend"...

    thanks
    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu


    --
    惠新宸 laruence
    Senior PHP Engineer
    http://www.laruence.com
  • Pierre Joye at Jul 22, 2014 at 2:58 am
    hi,

    aren't they discussed and voted? what do you mean by we can't even
    start in previous comment?
    The int64 yes, that means and it is/was not possible given the status
    of phpng in the last weeks, way too many huge changes.
    Or you suggest we stop the current work to waiting them come their self?

    I'm saying that we should resolve the current situation where people can't
    work on stuff which would target php-next, because it is still a moving
    target.
    why Nikita could work on it? why me can work on it?
    Who is asking you to work on that?

    I'm saying that it is pretty unfortunate that we have to decide to between
    reviewing/accepting a huuuuuuuge chunk of changes or rejecting a significant
    performance boost and some api cleanup.
    we shouldn't, at least most people here shouldn't, only the guys who
    need to maintain them should.
    Yes and no. phpng, as a whole, as it was done, as it is done, and as
    it is proposed forces us to this choice.

    I have asked very "early" (later on that) about your plans, and it was
    told it will not be the base for php-next and its aim is not to
    replace master. I expressed doubts, I see now that I was right.
    I'm saying that we should stop pushing our own agendas, and figure out the
    best possible solution for the current situation, so that we can go forward
    with the development with the normal workflow, where everybody is on the
    same page, controversial changes are done through RFCs and we don't block
    each other from the work.
    you know what? I really don't like "we should; we must", they means nothing..

    They mean a lot, really a lot.
    I have spent lots of my time to work on PHP/PHPNG, more than 80 hours
    per month.
    Oh very nice. Now what do you think we spend on the int64 patch? While
    you were saying that it is fine for master but rejecting it later on
    because of your secret work on phpng? I really do not like that.
    I treat it like a regular work, dmitry spends more than me(8 hours per day).

    you ask me to stop to wait somebody who even can not work hours a month here?
    It is called team work, with full time developers (very few) and other
    contributors, doing work on php in their free time (the waste
    majority). We have to respect the latter much more, much much more.
    with all my respects: I really upset by people who always told you,
    hey man, don't be rush...
    Nobody tells you not to rush to work on a given feature. However many
    did, and I'd to tell it again: do not to rush on pushing the next
    major release. The version we (all) have to maintain for the next
    decade. And by maintain it is not only about the core, it is about its
    extensions, be in core extensions and in PECL or other areas. A bad,
    unclean or broken APIs affect everyone, not only the few maintaining
    only one part of PHP, and only on one single platform. It will also
    affects end users projects, the health of a project affects everyone
    using it.
    because I am rushing, I have be rushing for months to make the work done..
    Most part of this work has been done in secret, without discussing
    with anyone but between you guys. While we were talking about our
    plans for php-next, even began the work, you were "rushing" to get
    phpng ready for the announce or release. You did not participate to
    any discussions nor proposed anything, not even mentioning your work
    on phpng. This is not the PHP I want to work with, it never was.

    Also rushing does not mean the work get done correctly. It is often
    the contrary. We can see that with phpng, you guys have worked very
    hard, but you worked in a bubble and now you come out of this bubble
    and tell us that it is all you want for next and that we should do it
    within a year. No, sorry, I can't and won't accept that.
    last of all : "all above is my personal comments, has nothing to do
    with Zend"...
    It has a lot to do with Zend given that Zend funds you to work on
    phpng and disallows you to communicate about it until it is announced
    (NDA). It is a shame to have NDAs to work on the core. It is a shame
    to come now and say things like "why should we wait for next if we
    (zend) are ready?" while having literally blocked everything since the
    announce of phpng.

    PHP-next is about a lot of things, way behind performance issues. You
    care only about that, but I, f.e., do care about performance only for
    20% of my priorities. Large PHP users told me the same. The needs,
    goals etc for php-next have been discussed and listed. Some of these
    todos have been worked on, publically, with periodic communications
    about the status, what has been done, etc. Discussing with many
    contributors, publicly, openly. This is how it should be. Yes, you do
    not like the "should" usage, but I repeat, it must be like that. If we
    can work on PHP openly, I fail to understand why Zend totally fail to
    do it.

    Now, as I already suggested many times (but with zero reply from
    Zend's), let step back, get our roadmap setup, todos, goals, agreement
    and get back to work. But a forcing move to php-next within a year
    with almost only phpng is a major mistake and will most likely create
    a major problem within the php community, especially for php.net. We
    are not in a positiion to do such mistake,. It is time to get our
    stuff together, to work as a team, this is out last chance, and phpng
    is not worth it in comparison.
  • Dmitry Stogov at Jul 22, 2014 at 6:44 am
    Pierre,

    I don't replay to you, because it's bad for my health. Many people here
    would agree with me.
    I prefer to do things instead of endlessly repeated words.

    According to PHPNG - we set one big goal (performance), and worked on it
    really hard. Now everyone may see the result. It's just not possible to
    solve all the goals at once and we didn't try to do it.

    Big PHP users just can't not to care about performance, because it's money.
    I know most of them already experimented with HHVM.
    If we don't provide adequate replay, we may turn back into the language for
    home pages.

    Thanks. Dmitry.



    On Tue, Jul 22, 2014 at 6:58 AM, Pierre Joye wrote:

    hi,

    aren't they discussed and voted? what do you mean by we can't even
    start in previous comment?
    The int64 yes, that means and it is/was not possible given the status
    of phpng in the last weeks, way too many huge changes.
    Or you suggest we stop the current work to waiting them come their
    self?

    I'm saying that we should resolve the current situation where people
    can't
    work on stuff which would target php-next, because it is still a moving
    target.
    why Nikita could work on it? why me can work on it?
    Who is asking you to work on that?

    I'm saying that it is pretty unfortunate that we have to decide to
    between
    reviewing/accepting a huuuuuuuge chunk of changes or rejecting a
    significant
    performance boost and some api cleanup.
    we shouldn't, at least most people here shouldn't, only the guys who
    need to maintain them should.
    Yes and no. phpng, as a whole, as it was done, as it is done, and as
    it is proposed forces us to this choice.

    I have asked very "early" (later on that) about your plans, and it was
    told it will not be the base for php-next and its aim is not to
    replace master. I expressed doubts, I see now that I was right.
    I'm saying that we should stop pushing our own agendas, and figure out
    the
    best possible solution for the current situation, so that we can go
    forward
    with the development with the normal workflow, where everybody is on the
    same page, controversial changes are done through RFCs and we don't
    block
    each other from the work.
    you know what? I really don't like "we should; we must", they means
    nothing..


    They mean a lot, really a lot.
    I have spent lots of my time to work on PHP/PHPNG, more than 80 hours
    per month.
    Oh very nice. Now what do you think we spend on the int64 patch? While
    you were saying that it is fine for master but rejecting it later on
    because of your secret work on phpng? I really do not like that.
    I treat it like a regular work, dmitry spends more than me(8 hours per day).
    you ask me to stop to wait somebody who even can not work hours a month
    here?

    It is called team work, with full time developers (very few) and other
    contributors, doing work on php in their free time (the waste
    majority). We have to respect the latter much more, much much more.
    with all my respects: I really upset by people who always told you,
    hey man, don't be rush...
    Nobody tells you not to rush to work on a given feature. However many
    did, and I'd to tell it again: do not to rush on pushing the next
    major release. The version we (all) have to maintain for the next
    decade. And by maintain it is not only about the core, it is about its
    extensions, be in core extensions and in PECL or other areas. A bad,
    unclean or broken APIs affect everyone, not only the few maintaining
    only one part of PHP, and only on one single platform. It will also
    affects end users projects, the health of a project affects everyone
    using it.
    because I am rushing, I have be rushing for months to make the work
    done..

    Most part of this work has been done in secret, without discussing
    with anyone but between you guys. While we were talking about our
    plans for php-next, even began the work, you were "rushing" to get
    phpng ready for the announce or release. You did not participate to
    any discussions nor proposed anything, not even mentioning your work
    on phpng. This is not the PHP I want to work with, it never was.

    Also rushing does not mean the work get done correctly. It is often
    the contrary. We can see that with phpng, you guys have worked very
    hard, but you worked in a bubble and now you come out of this bubble
    and tell us that it is all you want for next and that we should do it
    within a year. No, sorry, I can't and won't accept that.
    last of all : "all above is my personal comments, has nothing to do
    with Zend"...
    It has a lot to do with Zend given that Zend funds you to work on
    phpng and disallows you to communicate about it until it is announced
    (NDA). It is a shame to have NDAs to work on the core. It is a shame
    to come now and say things like "why should we wait for next if we
    (zend) are ready?" while having literally blocked everything since the
    announce of phpng.

    PHP-next is about a lot of things, way behind performance issues. You
    care only about that, but I, f.e., do care about performance only for
    20% of my priorities. Large PHP users told me the same. The needs,
    goals etc for php-next have been discussed and listed. Some of these
    todos have been worked on, publically, with periodic communications
    about the status, what has been done, etc. Discussing with many
    contributors, publicly, openly. This is how it should be. Yes, you do
    not like the "should" usage, but I repeat, it must be like that. If we
    can work on PHP openly, I fail to understand why Zend totally fail to
    do it.

    Now, as I already suggested many times (but with zero reply from
    Zend's), let step back, get our roadmap setup, todos, goals, agreement
    and get back to work. But a forcing move to php-next within a year
    with almost only phpng is a major mistake and will most likely create
    a major problem within the php community, especially for php.net. We
    are not in a positiion to do such mistake,. It is time to get our
    stuff together, to work as a team, this is out last chance, and phpng
    is not worth it in comparison.

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Lester Caine at Jul 22, 2014 at 7:11 am

    On 22/07/14 07:44, Dmitry Stogov wrote:
    Big PHP users just can't not to care about performance, because it's money.
    I know most of them already experimented with HHVM.
    Big users don't use PHP ...
    If we don't provide adequate replay, we may turn back into the language for
    home pages.
    Is that such a bad thing?
    Perhaps it is time there was a PHPHome and PHPCommercial ?
    Perhaps that is the problem these days :(

    --
    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
  • Dmitry Stogov at Jul 22, 2014 at 7:30 am

    On Tue, Jul 22, 2014 at 11:11 AM, Lester Caine wrote:
    On 22/07/14 07:44, Dmitry Stogov wrote:
    Big PHP users just can't not to care about performance, because it's money.
    I know most of them already experimented with HHVM.
    Big users don't use PHP ...
    You are wrong :)

    Thanks. Dmitry.

    If we don't provide adequate replay, we may turn back into the language for
    home pages.
    Is that such a bad thing?
    Perhaps it is time there was a PHPHome and PHPCommercial ?
    Perhaps that is the problem these days :(
    --
    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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Zeev Suraski at Jul 22, 2014 at 7:52 am

    -----Original Message-----
    From: Lester Caine
    Sent: Tuesday, July 22, 2014 10:12 AM
    To: PHP internals
    Subject: Re: [PHP-DEV] RFC: Move phpng to master

    Big users don't use PHP ...
    Just to elaborate (slightly) on Dmitry's answer - this is an absolutely
    wrong and also fairly dangerous misconception. PHP is the most widely used
    dynamic language out there for web sites, and it's used by many of the
    largest companies out there. In fact, there are very few companies that
    don't use PHP at all - whether it's for their main website or internal apps.

    Judging by the response to my benchmarks post (10K views in the first 5
    days, which I have to admit is very uncommon), the number of retweets,
    questions and discussions it sparked - I'd say the level of interest is
    very, very high.

    I do recommend that instead of wasting time arguing about theory, at least
    at this point, we focus on doing. The first logical step (in my humble
    opinion) is to move phpng into master and close any remaining gaps as
    quickly as possible.
    In parallel, people who want to get additional things into 6/7 should
    hustle, instead of assuming they have 2-3 years of lingering to rely on.
    RFCs we already agreed are going to be in the next version - like the
    uniform variable syntax and the 64-bit patch - will make it into master
    pretty quickly, I think we can count on Nikita here.

    For 6/7, we should primarily focus on things that we can only do in a major
    version - i.e. things that break compatibility. We should do so while
    keeping in mind that this is *not* an opportunity for wholesale breakage, as
    then we risk very slow or no migration (like we had between 4 and 5). New
    features can be added in the yearly .1/.2 releases too - so if they make it
    into .0 - great, but if not, no big deal. I stand by my statement that I'm
    sure a great deal of users (my guesstimate - the majority) would happily
    upgrade to PHP.NEXT even if the huge performance gains were the only thing
    there.

    Zeev
  • Pierre Joye at Jul 22, 2014 at 8:45 am
    hi,
    On Tue, Jul 22, 2014 at 9:52 AM, Zeev Suraski wrote:

    I stand by my statement that I'm
    sure a great deal of users (my guesstimate - the majority) would happily
    upgrade to PHP.NEXT even if the huge performance gains were the only thing
    there.
    I fully agree with you about breakages. It should be carefully for
    painful areas (like what is done in the variable syntax RFC) but big
    breaks should be avoided.

    However I disagree with your statement about what users expect for
    next. It is obvious that users are happy to see PHP performing better,
    there is no need to do a study to realize that. On the other hand,
    performance is not their higher priorities for the next major version.
    I spoke to many big php users, UG, etc in the last months and the
    expectations go way beyond performance. Internals code cleanup is very
    very important point (more and more custom extensions are being
    internally developed, be OSS or not), our APIs and implemenation are a
    mess, we all know that. A cleanup is long due, since the php 4 to 5
    move. Back then you, along other, rejected many of these cleanup
    arguing that it could be done later. Without blaming any of us, we see
    now that we never do such things "later".

    The other important parts are things like type hinting for scalar, to
    match the class type hinting, getter/setter (100% positive feedback to
    do what we proposed in the related RFC), object like methods for
    array/string, keeping BC with the existing APIs but providing cleaner
    userfriendlier APIs, etc. It is basically what we can find in the
    ideas page about php6, a page I created months ago and began to
    discuss. These discussions happened here, publically, and you
    (phpng's) never replied to any of them. This is what we should discuss
    now, not tomorrow, not when phpng is merged (if it ever happens). This
    is what allows us to do an informed guess for a possible release cycle
    for php-next. I will post a proposal for a timetable, something that
    could fit for both sides. Do not expect it to match your one year
    requirement, but it won't be three years either.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Benjamin Eberlei at Jul 22, 2014 at 9:19 am

    On Tue, Jul 22, 2014 at 10:45 AM, Pierre Joye wrote:

    hi,
    On Tue, Jul 22, 2014 at 9:52 AM, Zeev Suraski wrote:

    I stand by my statement that I'm
    sure a great deal of users (my guesstimate - the majority) would happily
    upgrade to PHP.NEXT even if the huge performance gains were the only thing
    there.
    Internals code cleanup is very very important point (more and more custom
    extensions are being
    internally developed, be OSS or not), our APIs and implemenation are a
    mess, we all know that. A cleanup is long due, since the php 4 to 5
    move.
    This is the opportunity to do the cleanup now, based on phpng branch. Since
    the branch is pulic on Github, how is development secret? With Zend, Nikita
    and laurence putting so much time into this, I fail to see how it would
    work to notify everyone of all the changes they are doing. As with every
    big project you have to put time into following its progress. I agree
    though that Zend (Zeev, Dimitry) could improve the RFC with a little more
    details, its focussing a lot on performance.

    As i understood Nikita and laurence they are already improving it based on
    the first prototype from month ago. Honestly, if Nikita says converting his
    extensions improved the API a lot then this is a good sign for me already.

    The other important parts are things like type hinting for scalar, to
    match the class type hinting, getter/setter (100% positive feedback to
    do what we proposed in the related RFC), object like methods for
    array/string, keeping BC with the existing APIs but providing cleaner
    userfriendlier APIs, etc. It is basically what we can find in the
    ideas page about php6, a page I created months ago and began to
    discuss. These discussions happened here, publically, and you
    (phpng's) never replied to any of them. This is what we should discuss
    now, not tomorrow, not when phpng is merged (if it ever happens). This
    is what allows us to do an informed guess for a possible release cycle
    for php-next. I will post a proposal for a timetable, something that
    could fit for both sides. Do not expect it to match your one year
    requirement, but it won't be three years either.
    I think internal refactoring is exactly the reason to move from 5 to 6/7
    and not necessarily end user facing changes. i wouldn't mind starting type
    hinting, getter/setter or any other discussion again once a 6.0/7.0 is out.
    This has worked for PHP since 5.3, 5.4, 5.5.

    I'd rather just take the performance gains, given that PHP as a language
    just works(tm), additional features are nice, but not having them is not a
    show stopper and shouldn't block something as big as phpng.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Pierre Joye at Jul 22, 2014 at 9:32 am

    On Tue, Jul 22, 2014 at 11:18 AM, Benjamin Eberlei wrote:

    This is the opportunity to do the cleanup now, based on phpng branch. Since
    the branch is pulic on Github, how is development secret?
    Benjamin, please check the background before replying. 80% of phpng
    development has been done secretly, before it was even announced. This
    development happened while we were discussing, collaborating, working
    on what will be php-next, including the long due 64bit patch. These
    actions and discussion have done without any feedback from any of the
    phpng developers. I can't blame them for not talking about phpng, but
    to have signed a NDA to do work on PHP itself.
    With Zend, Nikita
    and laurence putting so much time into this, I fail to see how it would work
    to notify everyone of all the changes they are doing. As with every big
    project you have to put time into following its progress. I agree though
    that Zend (Zeev, Dimitry) could improve the RFC with a little more details,
    its focussing a lot on performance.
    A little? There is no details, there is no doc, there is nothing but a
    huge set of patches.
    As i understood Nikita and laurence they are already improving it based on
    the first prototype from month ago. Honestly, if Nikita says converting his
    extensions improved the API a lot then this is a good sign for me already.
    It does not improve anything from an extension developer point of
    view, or very little. On the other APIs are more dangerous, confusing
    and inconsistent.

    The other important parts are things like type hinting for scalar, to
    match the class type hinting, getter/setter (100% positive feedback to
    do what we proposed in the related RFC), object like methods for
    array/string, keeping BC with the existing APIs but providing cleaner
    userfriendlier APIs, etc. It is basically what we can find in the
    ideas page about php6, a page I created months ago and began to
    discuss. These discussions happened here, publically, and you
    (phpng's) never replied to any of them. This is what we should discuss
    now, not tomorrow, not when phpng is merged (if it ever happens). This
    is what allows us to do an informed guess for a possible release cycle
    for php-next. I will post a proposal for a timetable, something that
    could fit for both sides. Do not expect it to match your one year
    requirement, but it won't be three years either.

    I think internal refactoring is exactly the reason to move from 5 to 6/7 and
    not necessarily end user facing changes. i wouldn't mind starting type
    hinting, getter/setter or any other discussion again once a 6.0/7.0 is out.
    This has worked for PHP since 5.3, 5.4, 5.5.
    Again once it is out? In which world do you live? that will never
    happen. We have an opportunity now to do it, let do it. Also I am very
    surprised to read that from you, I thought you were a strong supporter
    of these features, or annotations.
    I'd rather just take the performance gains, given that PHP as a language
    just works(tm), additional features are nice, but not having them is not a
    show stopper and shouldn't block something as big as phpng.
    It is. And performance is by no mean the main PHP problem, despite HHVM.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Lester Caine at Jul 22, 2014 at 9:41 am

    On 22/07/14 10:32, Pierre Joye wrote:
    As i understood Nikita and laurence they are already improving it based on
    the first prototype from month ago. Honestly, if Nikita says converting his
    extensions improved the API a lot then this is a good sign for me already.
    It does not improve anything from an extension developer point of
    view, or very little. On the other APIs are more dangerous, confusing
    and inconsistent.
    And unavailability of extensions is a blocker currently as well.

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

Related Discussions