Documenting APIs and merging ideas

11 years ago by Julien Pauli — view source

unread

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

11 years ago by Andrea Faulds — view source

unread

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/

11 years ago by Pierre Joye — view source

unread

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

11 years ago by Julien Pauli — view source

unread

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

11 years ago by Pierre Joye — view source

unread

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

11 years ago by Julien Pauli — view source

unread

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

11 years ago by Andrea Faulds — view source

unread

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/