Re: Documenting APIs and merging ideas

On Mon, May 26, 2014 at 12:59 PM, Pierre Joye <pierre.php@gmail.com> wrote: > 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. 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