Grokbase › Groups › PHP › php-internals › May 2014
FAQ
Hi :-)

I've been missing php-ng discussions for a while as the mailing lists
bounced for @php.net mails :-(

I finally subscribed wih another mail :-)

I can see that lots of work have been done on an implementation
actually called php-ng ; that's great !

I have no time myself to review it by now, but I hope it's right.
What I'd like to remind contributors about, is that we have some wiki
pages actually, summing up the ideas about PHP-next :

https://wiki.php.net/ideas/php6/engine
https://wiki.php.net/ideas/php6

Those sheets are writeable by anyone, and ideas already got added, cool !
Please, feel free to update them so that everyone is about of what's
happening for php-next.

I'd like myself to take the lead of several ideas :
- Extensions mechanism refactoring
- Annotations Support

Not sure when I'll have time to start those topics, but obviously
before PHP-next release :-)

Now I'd like people who are interested by some technical topics to
show up and try to build contributors teams to work on the same ideas.
(Perhaps adding a new wiki pages about groups could be an option ?)
However, I'm not sure about the best development process. As phpng is
a very huge branch that changed many things, how could people start
working on ideas (git workflow) ?

If some start hacking based on master, they'll hit problems the time
phpng gets merged (if it is to be merged). And the same applies
reversed : how can phpng contributors integrate in their branch ideas
from other developers and branches ?
Wasn't it the case for the int64 patch from Pierre ?

If one has ideas about a sain workflow, I would be very happy, as I
think I'm gonna start working on branches (and related RFCs) in a
couple of weeks.
I guess one branch per idea is a must-have, but how to manage rebases
so that each team/contributor spend the less possible time managing
this and the more time to produce effective code ?

Also, no-one should forget that PHP-Next is the right moment to clean
our APIs and finally refactor some code and get rid of some macro
hells as well as produce some documentation when one think API is
stable enough.
Do we have plans already about this ?

Thank you

Julien Pauli

Search Discussions

  • Andrea Faulds at May 26, 2014 at 10:53 am ⇧

    On 26 May 2014, at 11:37, Julien Pauli wrote:

    If some start hacking based on master, they'll hit problems the time
    phpng gets merged (if it is to be merged). And the same applies
    reversed : how can phpng contributors integrate in their branch ideas
    from other developers and branches ?
    Wasn't it the case for the int64 patch from Pierre ?
    This problem has been bothering me as well. There’s stuff I’d like to — or at least attempt to ;) — do in Zend, but phpng isn’t merged yet so I fear having to redo much of it once it’s merged.

    I suggest we only work on stuff which won’t touch Zend, or at least won’t touch stuff phpng touches, until phpng is merged. However, this is assuming phpng won’t take too long.
    --
    Andrea Faulds
    http://ajf.me/
  • Pierre Joye at May 26, 2014 at 11:00 am ⇧

    On Mon, May 26, 2014 at 12:52 PM, Andrea Faulds wrote:
    On 26 May 2014, at 11:37, Julien Pauli wrote:

    If some start hacking based on master, they'll hit problems the time
    phpng gets merged (if it is to be merged). And the same applies
    reversed : how can phpng contributors integrate in their branch ideas
    from other developers and branches ?
    Wasn't it the case for the int64 patch from Pierre ?
    This problem has been bothering me as well. There’s stuff I’d like to — or at least attempt to ;) — do in Zend, but phpng isn’t merged yet so I fear having to redo much of it once it’s merged.

    I suggest we only work on stuff which won’t touch Zend, or at least won’t touch stuff phpng touches, until phpng is merged. However, this is assuming phpng won’t take too long.
    Nice concept but due to its nature, phpng touches everything. Every
    single LoC related to zval, hash, or string are affected by the
    changes in phpng. The 2nd question is how to do not loose too much
    time until phpng gets some momentum. It will remain a moving target
    for the coming months (6+), can we afford to simply do almost nothing
    in the core from a design (APIs, cleanup, etc) for php 6 until phpng
    will be less than a moving target? Let alone RFC ready? I am not sure.

    I am not sure either about how to allow everyone to work on phpnext
    while stopping one team or another, right now it is all about
    performance, with promising results. While my personal priority would
    be rather to clean up the code base and the APIs along other things.
    No matter how, conflicts will happen. I tend too think that phpng
    should have more branches with individual changes, which can be merged
    to master individually. I can hardly think that having a bunch of mass
    changes being proposed in one go (the zpp change is a very good thing
    f.e., from a process pov).

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Julien Pauli at May 26, 2014 at 12:16 pm ⇧

    On Mon, May 26, 2014 at 12:59 PM, Pierre Joye wrote:
    On Mon, May 26, 2014 at 12:52 PM, Andrea Faulds wrote:
    On 26 May 2014, at 11:37, Julien Pauli wrote:

    If some start hacking based on master, they'll hit problems the time
    phpng gets merged (if it is to be merged). And the same applies
    reversed : how can phpng contributors integrate in their branch ideas
    from other developers and branches ?
    Wasn't it the case for the int64 patch from Pierre ?
    This problem has been bothering me as well. There’s stuff I’d like to — or at least attempt to ;) — do in Zend, but phpng isn’t merged yet so I fear having to redo much of it once it’s merged.

    I suggest we only work on stuff which won’t touch Zend, or at least won’t touch stuff phpng touches, until phpng is merged. However, this is assuming phpng won’t take too long.
    Nice concept but due to its nature, phpng touches everything. Every
    single LoC related to zval, hash, or string are affected by the
    changes in phpng. The 2nd question is how to do not loose too much
    time until phpng gets some momentum. It will remain a moving target
    for the coming months (6+), can we afford to simply do almost nothing
    in the core from a design (APIs, cleanup, etc) for php 6 until phpng
    will be less than a moving target? Let alone RFC ready? I am not sure.
    Obviously not.
    We are all working on an open source project, this means that everyone
    may propose anything (based on RFC) at any time, without the fear of
    meeting a future merge hell.

    How do other open source projects work when it comes to refactor and
    work on several branches, some of them beeing huge ?
    We should try to adopt a strategy here.
    I am not sure either about how to allow everyone to work on phpnext
    while stopping one team or another, right now it is all about
    performance, with promising results. While my personal priority would
    be rather to clean up the code base and the APIs along other things.
    No matter how, conflicts will happen. I tend too think that phpng
    should have more branches with individual changes, which can be merged
    to master individually. I can hardly think that having a bunch of mass
    changes being proposed in one go (the zpp change is a very good thing
    f.e., from a process pov).
    That's the key of the "success" I think.
    We all know it's always been better to work on several tiny changes
    than working on one big change. It is way easier to merge little
    patches than a big one, and it is as well easier for other developers
    to rebase on a branch in which small patches has been applied, than to
    rebase on a huge new tree.

    What is the strategy regarding phpng and merging option ?
    I fear if we try to merge it as a big solo merge, we'll never be able
    to rebase all the development branches from other contributors...
    It's better to discuss than now than to hit the wall later, no ?

    If one say phpng is to be merged in 6 months (for the example), it is
    sure that until this gap of time, other ideas will have popped in
    several branches and will hit the merge as well :-p

    Julien Pauli
  • Pierre Joye at May 26, 2014 at 11:02 am ⇧

    On Mon, May 26, 2014 at 12:37 PM, Julien Pauli wrote:

    Wasn't it the case for the int64 patch from Pierre ?
    As of now it is suspended. For two reasons:

    - the ML does not work, many did not follow the discussions or were
    not aware of it, in time
    - phpng is still a moving target and we should really have that patch
    with it, easier for everyone

    Once the ML is fixed, I will reset the votes, update the RFC (patch
    and contents) using phpng as base and more build options, providing
    more numbers for the various possible configurations.

    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Julien Pauli at May 26, 2014 at 12:08 pm ⇧

    On Mon, May 26, 2014 at 1:02 PM, Pierre Joye wrote:
    On Mon, May 26, 2014 at 12:37 PM, Julien Pauli wrote:

    Wasn't it the case for the int64 patch from Pierre ?
    As of now it is suspended. For two reasons:

    - the ML does not work, many did not follow the discussions or were
    not aware of it, in time
    - phpng is still a moving target and we should really have that patch
    with it, easier for everyone
    I fully agree here.
    Once the ML is fixed, I will reset the votes, update the RFC (patch
    and contents) using phpng as base and more build options, providing
    more numbers for the various possible configurations.
    This seems like a great consensus.


    Julien
  • Andrea Faulds at May 27, 2014 at 4:26 pm ⇧

    On 26 May 2014, at 11:37, Julien Pauli wrote:

    I have no time myself to review it by now, but I hope it's right.
    What I'd like to remind contributors about, is that we have some wiki
    pages actually, summing up the ideas about PHP-next :

    https://wiki.php.net/ideas/php6/engine
    https://wiki.php.net/ideas/php6
    Quite a few of these ideas have already been implemented in RFCs that now lie withdrawn (Anthony’s) or rejected (most of the other ones). I think we should start by updating their patches and holding new votes for these RFCs, but proposing merging into PHP6.
    --
    Andrea Faulds
    http://ajf.me/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 26, '14 at 10:38a
activeMay 27, '14 at 4:26p
posts7
users3
websitephp.net

3 users in discussion

Julien Pauli: 3 posts Pierre Joye: 2 posts Andrea Faulds: 2 posts

Content

People

Support

Translate

site design / logo © 2022 Grokbase