Documenting APIs and merging ideas

From: Date: Mon, 26 May 2014 10:37:17 +0000
Subject: Documenting APIs and merging ideas
Groups: php.internals 
Request: Send a blank email to internals+get-74497@lists.php.net to get a copy of this message
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

« previous php.internals (#74497) next »