Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74497 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16136 invoked from network); 26 May 2014 10:38:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 May 2014 10:38:01 -0000 Authentication-Results: pb1.pair.com smtp.mail=julienpauli@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=julienpauli@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.176 as permitted sender) X-PHP-List-Original-Sender: julienpauli@gmail.com X-Host-Fingerprint: 209.85.220.176 mail-vc0-f176.google.com Received: from [209.85.220.176] ([209.85.220.176:36448] helo=mail-vc0-f176.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3B/79-60353-88913835 for ; Mon, 26 May 2014 06:38:01 -0400 Received: by mail-vc0-f176.google.com with SMTP id id10so5626004vcb.35 for ; Mon, 26 May 2014 03:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=T5AjVP2bOWYuWzuz5llHncmKeGdI0kxrvkl89c8G348=; b=A8iOf4RSUfGFRM0nu9SJXl0MaPSYQjDlOhjzu3fcG5n4pG2c/Jf+P/5qdNYzeBsFnO TfJPqxSqZ32e1CfbS+/+snEDJ4xBy6bx07jwmK/pi16eIs7sSM14J/f/EcNy4bBMOi5D IrlS713vkM1SdU76XU2Sz4VVkuHnjhTcdLQR7PSG0Lud1uAAdGWQ17UC7AlZCYQy2nXB at93L4z4jEpnFBnhaOQrFjsKUolv134Z4Eowzs3xxKcQ8WOFAQ/R1nugQD0Jy8vkZeTd TV/3A+khsGu+D2VwmVszc9fkBVZsRnMwSC5KXXxnkmg3ae5hQPie+knvlQjAFNo8t+s4 HS2w== X-Received: by 10.220.167.2 with SMTP id o2mr20894760vcy.8.1401100677801; Mon, 26 May 2014 03:37:57 -0700 (PDT) MIME-Version: 1.0 Sender: julienpauli@gmail.com Received: by 10.220.81.68 with HTTP; Mon, 26 May 2014 03:37:17 -0700 (PDT) Date: Mon, 26 May 2014 12:37:17 +0200 X-Google-Sender-Auth: SpWnXVrjHb7VfwDEeb0qZ8cfYzc Message-ID: To: PHP Internals Content-Type: text/plain; charset=UTF-8 Subject: Documenting APIs and merging ideas From: jpauli@php.net (Julien Pauli) 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