Re: Documenting APIs and merging ideas

On Mon, May 26, 2014 at 12:52 PM, Andrea Faulds <ajf@ajf.me> wrote: > > On 26 May 2014, at 11:37, Julien Pauli <jpauli@php.net> 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