FAQ
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

Search Discussions

  • 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 :-)
  • 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.
  • 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
  • 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
    yohgaki@ohgaki.net
  • 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.
  • Derick Rethans at Jul 21, 2014 at 10:04 am

    On Mon, 21 Jul 2014, 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.

    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
    I was wondering whether there is an extension upgrading guide somewhere?
    I saw that https://wiki.php.net/phpng-int lists the changes to zvals,
    but it's not a guide and/or checklist on what to do for upgrading an
    extension. This, IMO, should include things such as:

    - which things needs changing
    - how object instanciation is now different
    - common pitfalls and errors.
    - etc.

    If there isn't such a thing, it's going to be quite necessary for 3rd
    party extension developers I'd say.

    cheers,
    Derick
  • 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: internals@lists.php.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
  • Zeev Suraski at Jul 21, 2014 at 10:18 am
    *From:* yohgaki@gmail.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
  • 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
  • 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
  • Ferenc Kovacs at Jul 21, 2014 at 10:24 am

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

    *From:* yohgaki@gmail.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
  • 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: internals@lists.php.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/
  • 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
  • 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
  • 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
  • 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/
  • 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: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
  • 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: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
  • 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
  • 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
  • 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
  • Nikita Popov at Jul 21, 2014 at 11:10 am

    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
    There are actually two questions here:
    1. Do we want to base the next major version on phpng?
    2. Do we want to merge phpng into master?

    The latter is tied to the question whether or not we want to have a PHP 5.7
    release in the meantime. I'm not really sure whether or not that would be
    good, I would recommend opening a separate thread about that question.

    Regarding the first question, I fully support basing the next major on
    phpng. Several people in this thread have raised concerns regarding the
    quality of phpng's API. As someone who has ported a number of extensions to
    be compatible with phpng and is currently in the process of writing a
    10kloc patch based on phpng, I can without any doubt say that the new APIs
    are a good bit more friendly to internals developers. Some of the reasons
    why that is so:

      * The removal of one level of zval indirection in many places, as well as
    the need to allocate zvals.
      * Changing the zend_hash APIs to directly return zvals/pointers and
    generally integrate better with zvals.
      * Changing the zend_hash APIs to handle lengths like everything else does.
      * The introduction of zend_string.

    From my perspective phpng's APIs are an improvement over the current state,
    however there is still a lot of room for improvement. E.g. there is still a
    huge number of macros, which should probably be moved to inline functions,
    etc. I don't think anyone has a problem with doing these kinds of
    improvements, but I don't think they are really relevant to the question at
    hand (as these cleanups can happen regardless of which branch is used as
    the basis). I'd also love it if we could drop TSRMLS_* - iirc joe has a
    partial patch for better TLS handling, which couldn't be used previously
    due to concerns over internal API breaks. For a new majors those concerns
    shouldn't be a problem anymore :)

    Regarding the stability of the phpng branch: phpng definitely still
    contains bugs (which is quite obvious given the amount of code it changes)
    and I'm aware that it currently fails with many large testsuites. Obviously
    this will have to be resolved by the time we get anywhere close to a
    release.

    However we cannot wait until all bugs have been fixed before continuing
    other development for php next. We need a basis for php next and we need it
    now, so people know what they should develop against. This way
    stabilization of phpng will happen in parallel to other changes.

    Nikita
  • 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
  • Ferenc Kovacs at Jul 21, 2014 at 11:20 am

    On Mon, Jul 21, 2014 at 1:10 PM, Nikita Popov wrote:
    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
    There are actually two questions here:
    1. Do we want to base the next major version on phpng?
    2. Do we want to merge phpng into master?

    The latter is tied to the question whether or not we want to have a PHP 5.7
    release in the meantime. I'm not really sure whether or not that would be
    good, I would recommend opening a separate thread about that question.
    either way, master should/will contain the changes from phpng, otherwise we
    would go against to our current merge everything upwards git workflow.
    but that doesn't really a problem for 5.7, we should just branch it from
    5.6 (we wanted to do this for 5.6 and 5.5, but most of the changes in
    master at that time was ok for a minor, so we branches from master instead
    of cherrypicking everything.), as anything we want to backport from master
    to 5.7 would require manual work to make it compatible with 5.7.

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

    On Mon, Jul 21, 2014 at 1:10 PM, Nikita Popov wrote:

    There are actually two questions here:
    1. Do we want to base the next major version on phpng?
    2. Do we want to merge phpng into master?
    As of now, I am against both. But as I said earlier I am open as long
    as the minimal requirements are met for an informed review and
    proposal.

    The latter is tied to the question whether or not we want to have a PHP 5.7
    release in the meantime. I'm not really sure whether or not that would be
    good, I would recommend opening a separate thread about that question.
    In the discussions about the actual roadmap for php-next, we discussed
    the idea of using 5.6 as base for 5.x. It leaves the door open for 5.7
    and 5.8, as perfectly valid options given my slightly more realistic
    time plan (2-3 years instead of 10 months). Master can then be
    phpnext.

    Regarding the first question, I fully support basing the next major on
    phpng. Several people in this thread have raised concerns regarding the
    quality of phpng's API. As someone who has ported a number of extensions to
    be compatible with phpng and is currently in the process of writing a
    10kloc patch based on phpng, I can without any doubt say that the new APIs
    are a good bit more friendly to internals developers. Some of the reasons
    why that is so:
    I used it, reviewed it (minus the additions done in the last couple of
    weeks) and I disagree. The APIs are more confusing, dangerous and far
    less consistent. Let alone the addition of countless macros, I doubt
    most of them are needed. ZPP is another one but Dmitry's last post say
    that it will be a separate RFC (hopefully).
    From my perspective phpng's APIs are an improvement over the current state,
    however there is still a lot of room for improvement. E.g. there is still a
    huge number of macros, which should probably be moved to inline functions,
    etc. I don't think anyone has a problem with doing these kinds of
    improvements, but I don't think they are really relevant to the question at
    hand (as these cleanups can happen regardless of which branch is used as
    the basis).
    It is, as it was for all the past RFCs, and to quote you: "I vote on
    what I see".
    I'd also love it if we could drop TSRMLS_* - iirc joe has a
    partial patch for better TLS handling, which couldn't be used previously
    due to concerns over internal API breaks. For a new majors those concerns
    shouldn't be a problem anymore :)
    Yes, TLS is definitively something I like to see in next.
    Regarding the stability of the phpng branch: phpng definitely still
    contains bugs (which is quite obvious given the amount of code it changes)
    and I'm aware that it currently fails with many large testsuites. Obviously
    this will have to be resolved by the time we get anywhere close to a
    release.
    We stopped testing it a couple of weeks as it was impossible to
    actually do it. It was a fast moving target until 2 weeks ago.
    However we cannot wait until all bugs have been fixed before continuing
    other development for php next.
    We did not wait phpng to do so. But for you, phpng was the prioritiy
    for the last months. And now you are telling us that you cannot wait
    to continue the developments? After having literally blocked us for
    months? Seriously, no. Now is the time to do one step back, look at
    the global picture and re start the discussions we began about next.
    And I serioulsly hope you guys will participate.
    We need a basis for php next and we need it
    now, so people know what they should develop against. This way
    stabilization of phpng will happen in parallel to other changes.
    We have one, it is called master. We have one with one cleanup being
    done already already, it is the 64bit branch. We can have even more,
    and in a much more stable state as phpng will ever be in the next 6
    months.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Zeev Suraski at Jul 21, 2014 at 12:32 pm

    On 21 ביול 2014, at 14:20, Ferenc Kovacs wrote:

    On Mon, Jul 21, 2014 at 1:10 PM, Nikita Popov wrote:
    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
    There are actually two questions here:
    1. Do we want to base the next major version on phpng?
    2. Do we want to merge phpng into master?

    The latter is tied to the question whether or not we want to have a PHP 5.7
    release in the meantime. I'm not really sure whether or not that would be
    good, I would recommend opening a separate thread about that question.

    either way, master should/will contain the changes from phpng, otherwise we would go against to our current merge everything upwards git workflow. Agreed.
    but that doesn't really a problem for 5.7, we should just branch it from 5.6 (we wanted to do this for 5.6 and 5.5, but most of the changes in master at that time was ok for a minor, so we branches from master instead of cherrypicking everything.), as anything we want to backport from master to 5.7 would require manual work to make it compatible with 5.7.
    Agreed too - I just think we should first focus on getting .NEXT released as soon as possible - and only branch away a 5.7 if we see it's taking too long. It's not a decision we need to take today, but if we were to do it, branching it from 5.6 sounds like the right way to do it.

    Zeev
  • Andrea Faulds at Jul 21, 2014 at 12:54 pm

    On 21 Jul 2014, at 12:10, Nikita Popov wrote:

    The latter is tied to the question whether or not we want to have a PHP 5.7
    release in the meantime. I'm not really sure whether or not that would be
    good, I would recommend opening a separate thread about that question.
    The way I see it, we should branch master to a new PHP-5.7 branch, and then merge phpng into master.

    I think we should have a PHP 5.7. There are plenty of things we can still do in the 5.x series and it would be better to get them into PHP next year with 5.7 rather than in two or three years with NEXT.

    On the other hand, keeping all the new features for PHP NEXT only provides more of an incentive to upgrade to 6.

    --
    Andrea Faulds
    http://ajf.me/
  • Zeev Suraski at Jul 21, 2014 at 1:06 pm

    -----Original Message-----
    From: Andrea Faulds
    Sent: Monday, July 21, 2014 3:55 PM
    To: Nikita Popov
    Cc: Zeev Suraski; PHP internals
    Subject: Re: [PHP-DEV] RFC: Move phpng to master


    I think we should have a PHP 5.7. There are plenty of things we can
    still do in
    the 5.x series and it would be better to get them into PHP next year with 5.7
    rather than in two or three years with NEXT.
    I'm not sure where the 2-3 years is coming from, but again, I see no
    reason why we wouldn't be able to push .NEXT out within a year (if it's
    just phpng along then actually a lot less, but I'm allowing time for extra
    features we may want to put in). As a matter of fact, I don't think we
    can even entertain a 2-3 cycle, it will be way too late to market if we
    linger for so long.

    This is the assumption we should take IMHO, and only branch 5.7 (and more
    importantly, invest time in it) if it proves wrong.

    Zeev
  • Andrea Faulds at Jul 21, 2014 at 1:10 pm

    On 21 Jul 2014, at 14:06, Zeev Suraski wrote:

    I'm not sure where the 2-3 years is coming from, but again, I see no
    reason why we wouldn't be able to push .NEXT out within a year (if it's
    just phpng along then actually a lot less, but I'm allowing time for extra
    features we may want to put in). As a matter of fact, I don't think we
    can even entertain a 2-3 cycle, it will be way too late to market if we
    linger for so long.
    We *could* make PHP NEXT in a year, sure, but it won’t be worthwhile being called PHP NEXT. There are a lot of big changes we can and should make and that would necessitate delaying it. Three years might be a bit long. However, I am confident that we need more than a year to make this major worth it.
    This is the assumption we should take IMHO, and only branch 5.7 (and more
    importantly, invest time in it) if it proves wrong.
    Branching 5.7 wouldn’t be a big effort. Master is fairly stable, and if some RFCs pass, we can merge them into 5.7. It also gives us a fallback. If PHP NEXT doesn’t happen next year (and I expect that it won’t), we’ll still have 5.7.
    --
    Andrea Faulds
    http://ajf.me/
  • Pierre Joye at Jul 21, 2014 at 1:16 pm

    On Mon, Jul 21, 2014 at 3:06 PM, Zeev Suraski wrote:

    I'm not sure where the 2-3 years is coming from, but again, I see no
    reason why we wouldn't be able to push .NEXT out within a year (if it's
    just phpng along then actually a lot less, but I'm allowing time for extra
    features we may want to put in). As a matter of fact, I don't think we
    can even entertain a 2-3 cycle, it will be way too late to market if we
    linger for so long.

    This is the assumption we should take IMHO, and only branch 5.7 (and more
    importantly, invest time in it) if it proves wrong.
    This is the assumption we should not take. It is disturbing to see you
    pushing again something so hard that it will hurt the whole project.
    And this time much harder than in the last times.

    It is time to step back and take a realistic view of what is going,
    outside your book, which is barely based on your one and only
    prioritiy, performance (and only one platform too). This is not PHP,
    not what many want. And even I am pretty sure you will make it through
    with this totally incomplete RFC based on disputable benchmarks and no
    matter how much performance improvements happen with phpng, this is
    not the only thing what we should do in next. Even if it was, to think
    about being ready in less than a year is a sweet dream, to say it
    nicely.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Zeev Suraski at Jul 21, 2014 at 1:47 pm

    -----Original Message-----
    From: Andrea Faulds
    Sent: Monday, July 21, 2014 4:10 PM
    To: Zeev Suraski
    Cc: Nikita Popov; PHP internals
    Subject: Re: [PHP-DEV] RFC: Move phpng to master


    We *could* make PHP NEXT in a year, sure, but it won't be worthwhile being
    called PHP NEXT.
    Everything I know about the PHP community, combined with the amazing level
    of interest that the recent PHPNG benchmarks garnered, tells me that it
    wrong.
    People would love to get it even if it was just the performance & memory
    footprint gains alone. And we're not even talking about that - we'd still
    have ample time to put in additional features into it.
    There are a lot of big changes we can and should make and
    that would necessitate delaying it. Three years might be a bit long.
    Three years is a lifetime in our world of software...
    However, I
    am confident that we need more than a year to make this major worth it.
    Even if it's going to be 18 months (which is on the upper limit of what I
    think we should allow for .NEXT), I don't see a need for 5.7 in between.
    When we created the release process RFC, from the get go, I thought that
    releasing every 12 months is too frequent. I was told not to worry and
    that we'll "see how it goes" and "change if we need to". Now, suddenly
    this became a God-given commandment, that we must have a mini version
    every year and on time - and it's not. Reality is that the userbase is
    embracing versions a lot slower than we crank them up - releasing 5.7 to
    be followed shortly by 6/7 doesn't make a lot of sense, I think.

    Still, I think we're much better off delivering .NEXT as soon as we can
    as.
    This is the assumption we should take IMHO, and only branch 5.7 (and
    more importantly, invest time in it) if it proves wrong.
    Branching 5.7 wouldn't be a big effort. Master is fairly stable, and if some RFCs
    pass, we can merge them into 5.7. It also gives us a fallback. If PHP NEXT
    doesn't happen next year (and I expect that it won't), we'll still have
    5.7.

    I can live with that, as long as we treat 5.7 as a secondary project where
    we backport stuff rom master, and as long as it's clear to everyone that
    it may be (or IMHO may very well be) throw-away code that we'll never
    actually use. Personally I think it makes more sense to focus on getting
    .NEXT out the door quickly so that we don't have to get into the headache
    of working on two active trees, though. I'd like to see what others are
    thinking...

    Zeev
  • Andrea Faulds at Jul 21, 2014 at 1:51 pm

    On 21 Jul 2014, at 14:47, Zeev Suraski wrote:

    Everything I know about the PHP community, combined with the amazing level
    of interest that the recent PHPNG benchmarks garnered, tells me that it
    wrong.
    People would love to get it even if it was just the performance & memory
    footprint gains alone. And we're not even talking about that - we'd still
    have ample time to put in additional features into it.
    Yes, “additional” features. Not big ones. That is my point of contention: if the only major engine-level thing we have time to add is phpng’s performance improvements, I’m not sure it’s worthy of being PHP NEXT.
    This is the assumption we should take IMHO, and only branch 5.7 (and
    more importantly, invest time in it) if it proves wrong.
    Branching 5.7 wouldn't be a big effort. Master is fairly stable, and if some RFCs
    pass, we can merge them into 5.7. It also gives us a fallback. If PHP NEXT
    doesn't happen next year (and I expect that it won't), we'll still have
    5.7.

    I can live with that, as long as we treat 5.7 as a secondary project where
    we backport stuff rom master, and as long as it's clear to everyone that
    it may be (or IMHO may very well be) throw-away code that we'll never
    actually use. Personally I think it makes more sense to focus on getting
    .NEXT out the door quickly so that we don't have to get into the headache
    of working on two active trees, though. I'd like to see what others are
    thinking…
    Well, I don’t think that, realistically, introducing PHP NEXT will immediately kill the 5.x line. We should have at least one more release after NEXT comes out. That release will probably be 5.7, and who knows, perhaps it might actually come out *after* NEXT.
    --
    Andrea Faulds
    http://ajf.me/
  • Pierre Joye at Jul 21, 2014 at 2:06 pm
    On Mon, Jul 21, 2014 at 3:47 PM, Zeev Suraski wrote:
    d PHP NEXT.
    Everything I know about the PHP community, combined with the amazing level
    of interest that the recent PHPNG benchmarks garnered, tells me that it
    wrong.
    You needed one year+ to stabilize opcache, how long will you need for
    something as huge as phpng? Along with giving the chance to other to
    actually do what we expect in the next major version? In my book it is
    more than a year, and between two and three years is a reasonable
    timeframe.
    People would love to get it even if it was just the performance & memory
    footprint gains alone. And we're not even talking about that - we'd still
    have ample time to put in additional features into it.
    People tells me something else. But we surely speak to totally different people.

    There are a lot of big changes we can and should make and
    that would necessitate delaying it. Three years might be a bit long.
    Three years is a lifetime in our world of software...
    Are nothing.

    Even if it's going to be 18 months (which is on the upper limit of what I
    think we should allow for .NEXT), I don't see a need for 5.7 in between.
    It is per se defined to have a 5.7 next year. I do not see how it
    could be remotely possible to have php-next ready by June 2015, except
    if you release something not ready and did the same that we did before
    "we will fix/clean that later", which indeed never happened.
    When we created the release process RFC, from the get go, I thought that
    releasing every 12 months is too frequent. I was told not to worry and
    that we'll "see how it goes" and "change if we need to".
    We can adapt the RFC, not let a company adapts it as they wish as you
    seems to like to do.
    Now, suddenly
    this became a God-given commandment, that we must have a mini version
    every year and on time - and it's not. Reality is that the userbase is
    embracing versions a lot slower than we crank them up - releasing 5.7 to
    be followed shortly by 6/7 doesn't make a lot of sense, I think.
    Adoption of new versions is increasing, drastically, because of the
    release process RFC. That is what many major big companies using PHP
    tell me as well as what the numbers I can see tell me.
    Still, I think we're much better off delivering .NEXT as soon as we can
    as.
    As soon as we can? Hell yeah. I cannot agree more here. And as soon as
    we can is not as soon as you wish or as soon as you consider phpng
    release ready (in theory).

    This is the assumption we should take IMHO, and only branch 5.7 (and
    more importantly, invest time in it) if it proves wrong.
    Branching 5.7 wouldn't be a big effort. Master is fairly stable, and if some RFCs
    pass, we can merge them into 5.7. It also gives us a fallback. If PHP NEXT
    doesn't happen next year (and I expect that it won't), we'll still have
    5.7.

    I can live with that, as long as we treat 5.7 as a secondary project where
    we backport stuff rom master, and as long as it's clear to everyone that
    it may be (or IMHO may very well be) throw-away code that we'll never
    actually use. Personally I think it makes more sense to focus on getting
    .NEXT out the door quickly so that we don't have to get into the headache
    of working on two active trees, though. I'd like to see what others are
    thinking...
    I have no issue working with many trees, CIs get better every day,
    testing PRs are now automated, travis support for more platforms is
    coming, everything coming together to increase php and related
    projects quality.

    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/
  • Derick Rethans at Jul 21, 2014 at 2:09 pm

    On Mon, 21 Jul 2014, Zeev Suraski wrote:

    From: Andrea Faulds
    We *could* make PHP NEXT in a year, sure, but it won't be worthwhile
    being called PHP NEXT.
    Everything I know about the PHP community, combined with the amazing
    level of interest that the recent PHPNG benchmarks garnered, tells me
    that it wrong.
    People would love to get it even if it was just the performance &
    memory footprint gains alone. And we're not even talking about that -
    we'd still have ample time to put in additional features into it.
    There are a lot of big changes we can and should make and that would
    necessitate delaying it. Three years might be a bit long.
    Three years is a lifetime in our world of software...
    However, I am confident that we need more than a year to make this
    major worth it.
    Even if it's going to be 18 months (which is on the upper limit of
    what I think we should allow for .NEXT), I don't see a need for 5.7 in
    between. When we created the release process RFC, from the get go, I
    thought that releasing every 12 months is too frequent. I was told
    not to worry and that we'll "see how it goes" and "change if we need
    to". Now, suddenly this became a God-given commandment, that we must
    have a mini version every year and on time - and it's not. Reality is
    that the userbase is embracing versions a lot slower than we crank
    them up - releasing 5.7 to be followed shortly by 6/7 doesn't make a
    lot of sense, I think.

    Still, I think we're much better off delivering .NEXT as soon as we
    can as.
    I think that's the cru - and very important. I would totally be in
    favour with PHP 7 be "just" PHPNG - as long of course it's finished.
    Whether this takes slightly more than a year, I don't really care.
    This is the assumption we should take IMHO, and only branch 5.7
    (and more importantly, invest time in it) if it proves wrong.
    Branching 5.7 wouldn't be a big effort. Master is fairly stable, and
    if some RFCs pass, we can merge them into 5.7. It also gives us a
    fallback. If PHP NEXT doesn't happen next year (and I expect that it
    won't), we'll still have 5.7.
    I can live with that, as long as we treat 5.7 as a secondary project
    where we backport stuff rom master, and as long as it's clear to
    everyone that it may be (or IMHO may very well be) throw-away code
    that we'll never actually use. Personally I think it makes more sense
    to focus on getting .NEXT out the door quickly so that we don't have
    to get into the headache of working on two active trees, though. I'd
    like to see what others are thinking...
    I agree. We should not focus on two active trees.

    cheers,
    Derick
  • 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
  • Xinchen Hui at Jul 21, 2014 at 3:23 pm
    Hey:
    在 2014年7月21日,18:56,Pierre Joye <pierre.php@gmail.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
  • Xinchen Hui at Jul 21, 2014 at 3:28 pm

    Hey:

    在 2014年7月21日,19:02,Ferenc Kovacs <tyra3l@gmail.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 <pierre.php@gmail.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 <tyra3l@gmail.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 <tyra3l@gmail.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

Related Discussions

People

Translate

site design / logo © 2018 Grokbase