On Mon, Jul 21, 2014 at 1:10 PM, Nikita Popov <nikita....@gmail.com> wrote:
> There are actually two questions here: > 1. Do we want to base the next major version on phpng? > 2. Do we want to merge phpng into master? As of now, I am against both. But as I said earlier I am open as long as the minimal requirements are met for an informed review and proposal. > The latter is tied to the question whether or not we want to have a PHP 5.7 > release in the meantime. I'm not really sure whether or not that would be > good, I would recommend opening a separate thread about that question. In the discussions about the actual roadmap for php-next, we discussed the idea of using 5.6 as base for 5.x. It leaves the door open for 5.7 and 5.8, as perfectly valid options given my slightly more realistic time plan (2-3 years instead of 10 months). Master can then be phpnext. > Regarding the first question, I fully support basing the next major on > phpng. Several people in this thread have raised concerns regarding the > quality of phpng's API. As someone who has ported a number of extensions to > be compatible with phpng and is currently in the process of writing a >>10kloc patch based on phpng, I can without any doubt say that the new APIs > are a good bit more friendly to internals developers. Some of the reasons > why that is so: I used it, reviewed it (minus the additions done in the last couple of weeks) and I disagree. The APIs are more confusing, dangerous and far less consistent. Let alone the addition of countless macros, I doubt most of them are needed. ZPP is another one but Dmitry's last post say that it will be a separate RFC (hopefully). > From my perspective phpng's APIs are an improvement over the current state, > however there is still a lot of room for improvement. E.g. there is still a > huge number of macros, which should probably be moved to inline functions, > etc. I don't think anyone has a problem with doing these kinds of > improvements, but I don't think they are really relevant to the question at > hand (as these cleanups can happen regardless of which branch is used as > the basis). It is, as it was for all the past RFCs, and to quote you: "I vote on what I see". > I'd also love it if we could drop TSRMLS_* - iirc joe has a > partial patch for better TLS handling, which couldn't be used previously > due to concerns over internal API breaks. For a new majors those concerns > shouldn't be a problem anymore :) Yes, TLS is definitively something I like to see in next. > Regarding the stability of the phpng branch: phpng definitely still > contains bugs (which is quite obvious given the amount of code it changes) > and I'm aware that it currently fails with many large testsuites. Obviously > this will have to be resolved by the time we get anywhere close to a > release. We stopped testing it a couple of weeks as it was impossible to actually do it. It was a fast moving target until 2 weeks ago. > However we cannot wait until all bugs have been fixed before continuing > other development for php next. We did not wait phpng to do so. But for you, phpng was the prioritiy for the last months. And now you are telling us that you cannot wait to continue the developments? After having literally blocked us for months? Seriously, no. Now is the time to do one step back, look at the global picture and re start the discussions we began about next. And I serioulsly hope you guys will participate. > We need a basis for php next and we need it > now, so people know what they should develop against. This way > stabilization of phpng will happen in parallel to other changes. We have one, it is called master. We have one with one cleanup being done already already, it is the 64bit branch. We can have even more, and in a much more stable state as phpng will ever be in the next 6 months. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
