Re: [PHP-DEV] RFC: Move phpng to master
On 27 07 2014, at 02:53, Kris Craig kris.cr...@gmail.com wrote: So even IF you want to reduce the scope of the 2/3 requirement to language impacts in userland only, your RFC *still* falls under that requirement because it directly affects the language itself in userland, as described above. I would again invite you to reconsider your position on this and avoid a protracted fight on this that would only serve to split the community. I’m actually not sure why we even have to vote on PHP-NG? How about for the crusaders to build something comparable to put up to vote against PHP-NG? There isn’t? Well, then let’s go ahead. Simple. Rolling eyes, Mike PS: My dog wants voting rights because he feels like he’ll be affected by changes to PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Sat, Jul 26, 2014 at 11:10 PM, Michael Wallner mike.php@gmail.com wrote: On 27 07 2014, at 02:53, Kris Craig kris.cr...@gmail.com wrote: So even IF you want to reduce the scope of the 2/3 requirement to language impacts in userland only, your RFC *still* falls under that requirement because it directly affects the language itself in userland, as described above. I would again invite you to reconsider your position on this and avoid a protracted fight on this that would only serve to split the community. I’m actually not sure why we even have to vote on PHP-NG? How about for the crusaders to build something comparable to put up to vote against PHP-NG? There isn’t? Well, then let’s go ahead. Simple. To answer your question (sort-of), the alternative to PHP-NG is what we have right now. I can't speak for anyone else, of course, but I certainly am not opposed to PHP-NG, even though Zeev seems to think so. I just don't think it's ready to be merged into master yet, based on everything I've seen, including concerns raised by others more knowledgeable than I on this list. I also just want to make sure something so massive in scope isn't pushed through by a slim majority, especially since doing so would violate the Voting RFC as it's currently written and would probably lead to an ugly fight among those who have RW+ access. I actually like PHP-NG and what it strives to do. I just think its developers are jumping the gun and trying to force something through that many in the community feel is not yet ready for deployment. I honestly don't understand why there's such a rush and why people who are calling for things to slow down so that cooler heads can prevail are being demonized and mocked. It's not you're either with us or you're against us. I don't oppose PHP-NG simply because I want to make sure all the ducks are in a row before it's deployed. Here's my question to counter yours, Michael: What's the rush? --Kris
Re: [PHP-DEV] RFC: Move phpng to master
On Sun, Jul 27, 2014 at 8:10 AM, Michael Wallner mike.php@gmail.com wrote: On 27 07 2014, at 02:53, Kris Craig kris.cr...@gmail.com wrote: So even IF you want to reduce the scope of the 2/3 requirement to language impacts in userland only, your RFC *still* falls under that requirement because it directly affects the language itself in userland, as described above. I would again invite you to reconsider your position on this and avoid a protracted fight on this that would only serve to split the community. I’m actually not sure why we even have to vote on PHP-NG? As it is surely a rhetoric question, let leave it, ok? How about for the crusaders to build something comparable to put up to vote against PHP-NG? There isn’t? Well, then let’s go ahead. Simple. Rolling eyes, Mike PS: My dog wants voting rights because he feels like he’ll be affected by changes to PHP. This kind of post surely brings us a huge step forward. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote: Here's my question to counter yours, Michael: What's the rush? Every day php-ng is not GA, PHP is losing ground to its competitors. People seem to ignore this because of cosmetics.
Re: [PHP-DEV] RFC: Move phpng to master
On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote: Here's my question to counter yours, Michael: What's the rush? Every day php-ng is not GA, PHP is losing ground to its competitors. Umm, how? Do you have any data to support this? According to http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing. As far as our competitors are concerned, well: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python As you can see, PHP continues to dominate with over 80% market share and no signs-- at least, none that I can see-- that we are losing ground as you stated. So again: What's the rush? --Kris
Re: [PHP-DEV] RFC: Move phpng to master
On 27/07/14 07:23, Kris Craig wrote: Here's my question to counter yours, Michael: What's the rush? I think that the only 'objection' I have to 'simply' merging phpng is that it is not just a 'single' change? This vote is all or nothing, so every change is bundled without a vote on particular elements. That many elements ARE simply improvements to the speed at which things are processed is not the problem here, and it may well be that the changes that do affect BC have a practical justification, but there will not be a discussion on that? I'm currently fighting a problem due to a blanket change to a number of systems, which offer a vast speed improvement, but now apparently make it impossible to identify the location of the client machine. The change to VDI is a done deal but nobody on site seems to be interested in fixing the resulting problem :( Due diligence would have addressed the problem beforehand and could well have steered things a different way. The 'rush' with phpng is that people need to have a stable base to be working with, and if php-next is to be phpng, then we need to be working with it. If I magically found some spare time today should I be looking at the current code base or phpng going forward? Documentation IS crucial here, and documenting those changes and providing information where an individual change affects BC is essential, but there should be some mechanism to review elements that are not so clear cut? IS_BOOL object container against IS_TRUE and IS_FALSE new values is probably not a good example, but it is a change that I don't currently see full rational behind ... if I create a bool container I don't know which value it is ... We do not want to complicate things by voting on each element, but it's the simple fact that so many elements have been re-engineered without the normal process that is causing irritation, so some agreement that if questions are raised about an element then it WILL get a proper discussion and if justified get reverted? I think that this is part of the debate on 2/3rds or 50-50 ... there are elements which would normally be a 2/3rds decision? So there should be an agreement that these can be reviewed again later? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On 27/07/14 08:26, Kris Craig wrote: As you can see, PHP continues to dominate with over 80% market share and no signs-- at least, none that I can see-- that we are losing ground as you stated. So again: What's the rush? Especially since 75% of that are still on PHP5.3 or 5.2 ;) But I had forgotten the comparison has a breakdown by ranking. I made the unsubstantiated comment about big sites not using PHP which of cause this shows, but there is no reference to the alternative PHP engines? One question that does come too mind is Why is python so popular with the bigger sites? Is it because compiled builds are fully supported? Certainly if any of my own sites traffic started to take off I would be looking down that avenue, so while improving the speed of interpreted working is important, it is still stability in the language that blocks uptake? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On 27 Jul 2014 09:26, Kris Craig kris.cr...@gmail.com wrote: On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote: Here's my question to counter yours, Michael: What's the rush? Every day php-ng is not GA, PHP is losing ground to its competitors. Umm, how? Do you have any data to support this? According to http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing. As far as our competitors are concerned, well: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python As you can see, PHP continues to dominate with over 80% market share and no signs-- at least, none that I can see-- that we are losing ground as you stated. Surely it's wise to make the same wrong assumptions Microsoft did with Internet Explorer?
Re: [PHP-DEV] RFC: Move phpng to master
On Sun, Jul 27, 2014 at 1:03 AM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 09:26, Kris Craig kris.cr...@gmail.com wrote: On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote: Here's my question to counter yours, Michael: What's the rush? Every day php-ng is not GA, PHP is losing ground to its competitors. Umm, how? Do you have any data to support this? According to http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing. As far as our competitors are concerned, well: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python As you can see, PHP continues to dominate with over 80% market share and no signs-- at least, none that I can see-- that we are losing ground as you stated. Surely it's wise to make the same wrong assumptions Microsoft did with Internet Explorer? Again, where's your evidence, Michael? I provided two separate sources that provide data showing that PHP is *gaining* market share and continues to dominate over the competition, which directly contradicts the claim you made. Simply brushing this factual data as wrong assumptions-- without any data of your own to back-up that claim-- does not constitute a valid counter-argument, nor does introducing a non sequitur by comparing PHP to Internet Explorer. These aren't assumptions, wrong or otherwise. This is data pulled from reliable sources. If you have separate data that calls it into question, then please share it with us. Otherwise, you're just making baseless and factually inaccurate claims about PHP to justify your argument about PHP-NG. As far as I can tell from the evidence available, your statement that PHP is losing ground to its competitors appears to be false. In fact, the exact opposite appears to be true. Again, that's not an assumption. That's just looking at the available data. --Kris
Re: [PHP-DEV] RFC: Move phpng to master
On 27 07 2014, at 11:44, Kris Craig kris.cr...@gmail.com wrote: [a lot] Maybe because you see those as competitors, but I see HHVM and friends as current competitors, being evaluated to replace stock PHP, which is definitely not covered by any nice statistics you can currently view. Cheers, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
Instead of endless, useless bickering, how about everyone both for and against merging jump in and start helping with phpng (docs, api cleanup/stabilization, but fixes, etc)? Imagine how much more stable and ready to merge it would be if you concentrated the saber rattling energy towards actually accomplishing something. On Sun, Jul 27, 2014 at 6:00 AM, Michael Wallner mike.php@gmail.com wrote: On 27 07 2014, at 11:44, Kris Craig kris.cr...@gmail.com wrote: [a lot] Maybe because you see those as competitors, but I see HHVM and friends as current competitors, being evaluated to replace stock PHP, which is definitely not covered by any nice statistics you can currently view. Cheers, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
Hi all, On Sun, Jul 27, 2014 at 5:03 PM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 09:26, Kris Craig kris.cr...@gmail.com wrote: On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote: Here's my question to counter yours, Michael: What's the rush? Every day php-ng is not GA, PHP is losing ground to its competitors. Umm, how? Do you have any data to support this? According to http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing. As far as our competitors are concerned, well: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python As you can see, PHP continues to dominate with over 80% market share and no signs-- at least, none that I can see-- that we are losing ground as you stated. Surely it's wise to make the same wrong assumptions Microsoft did with Internet Explorer? PHP is losing as a general scripting language for sure. JavaScript is winning in this area even if it was originated as a web client scripting language. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://langpop.com/ We are better to consider this situation seriously. IMHO. Focus on web as well as encourage general usage is what we need. Making PHP a choice for new project should be one of the most important objective. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: Move phpng to master
On Sun, Jul 27, 2014 at 3:00 AM, Michael Wallner mike.php@gmail.com wrote: On 27 07 2014, at 11:44, Kris Craig kris.cr...@gmail.com wrote: [a lot] Maybe because you see those as competitors, You're the one who said PHP was losing ground to its competitors, not I. but I see HHVM and friends as current competitors, being evaluated to replace stock PHP, which is definitely not covered by any nice statistics you can currently view. So, in other words, you're basing your claim on anecdotal and purely hypothetical assumptions about unnamed people evaluating other languages to replace PHP. Even if your self-serving guess were true, for which there is no evidence that has been presented here, it still wouldn't substantiate your claim because evaluating alternatives to your current codebase doesn't mean you're going to actually switch to any of them. So either way, PHP is not, as you claimed, losing ground to anyone. [a lot] I've been trying to maintain a civil discussion here, but I have to say, Michael, thus far you have done nothing but make immature, snyde personal attacks and baseless, factually inaccurate claims. You have not contributed anything substantive or constructive to this debate up to this point. From your rolling eyes comment where you speculated about your dog wanting voting rights to now, you have been very disrespectful and uncivil toward everyone here. I don't want to discourage anyone from expressing their views, but on the same token, I'm not here to feed trolls. This issue clearly brings out strong emotions in some people and we clearly disagree on certain points. That said, please make a greater effort to be respectful toward other people on this list, whether you agree with them or not. Your trolling comments have all but hijacked this thread over the last 17 hours and it's detracting from substantive debate that needs to happen. If you have some issue with me personally, please take it off-list. If you're going to post further on this thread, please try to be more respectful and mature in your comments. --Kris http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js
Re: [PHP-DEV] RFC: Move phpng to master
On Sun, Jul 27, 2014 at 3:54 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Sun, Jul 27, 2014 at 5:03 PM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 09:26, Kris Craig kris.cr...@gmail.com wrote: On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote: Here's my question to counter yours, Michael: What's the rush? Every day php-ng is not GA, PHP is losing ground to its competitors. Umm, how? Do you have any data to support this? According to http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing. As far as our competitors are concerned, well: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python As you can see, PHP continues to dominate with over 80% market share and no signs-- at least, none that I can see-- that we are losing ground as you stated. Surely it's wise to make the same wrong assumptions Microsoft did with Internet Explorer? PHP is losing as a general scripting language for sure. JavaScript is winning in this area even if it was originated as a web client scripting language. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://langpop.com/ We are better to consider this situation seriously. IMHO. Focus on web as well as encourage general usage is what we need. Making PHP a choice for new project should be one of the most important objective. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net According to w3techs, JavaScript retains an extremely tiny market share in terms of general purpose languages: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js It looks like the sources are all measuring different metrics. It would be interesting to see a closer analysis of the data and figure out which metrics are the most relevant to this question. --Kris
Re: [PHP-DEV] RFC: Move phpng to master
Hi Kris, On Mon, Jul 28, 2014 at 9:18 AM, Kris Craig kris.cr...@gmail.com wrote: According to w3techs, JavaScript retains an extremely tiny market share in terms of general purpose languages: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js It looks like the sources are all measuring different metrics. It would be interesting to see a closer analysis of the data and figure out which metrics are the most relevant to this question. Since we have enough market share on web apps already, why don't we focus more on developers? There are many awesome none web app tools that are developed with JavaScript because of it's popularity and developers' passion. PHP is losing popularity for sure. http://www.tiobe.com/index.php/content/paperinfo/tpci/PHP.html PHP is the worst in terms of lost popularity among top 20 languages. It should be a flag for us to adjust our strategy/view. Market share comes after language popularity. When market share has changed, it would be too late. Anyway, I'm willing to have phpng as master, as well as INT64 branch. Both are good for PHP. IMO. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: Move phpng to master
First off, I realize I am top posting but this thread is becoming extremely off-topic, unbalanced and overall ridiculous to see from the sidelines as someone that contributes to open source and also utilizes PHP on a daily basis for more than the last decade. Seriously, cut the shit! Everyone is bringing this to a personal and completely insane area; let's focus on the facts not the reactions wherever they might come from. Work together, no one ever agrees 100% of the time and continuing on that note, no one makes the best choices 100% of the time. Surely, as a community we will not always agree on implementations, timing and what is done in secret vs. not, what is more maintainable vs. what is not. Where to dedicate focus etc. Open source projects often have this issue. Also, no I am not taking a stance or side on what is best for the language. People contributing to the engine are much smarter than I in this level and the right choice I am certain will prevail. But have a reasonable conversations on facts vs. personal opinions and vendettas. Now, PHP is a balanced language; performance comes with a cost if it be memory, CPU spikes, maintainability, readability, etc. We all program here; this is always a trade off we need to determine, analyze and identify. These things have to be taken into account. Documentation is nice but not always necessary. Depending on what it will change and how much affect it will have on say extension developers and existing people contributing to core has to be taken into account. Let's get our heads straight, determine our focus for the next few years and start to move forward. Sure other languages gain and lose on PHP but this will always be the case and should not be the core focus; we're not a company that's on the stock market. Languages will evolve, change, become invented but it's not like PHP is going away in a rapid decline; sure there is more languages and more competition out there. For instance, I have been writing node.js lately and find a massive benefit in certain types of projects; it comes to utilizing the right tool for the right job. Surely you are not going to attempt to write PHP for something that should be done in assembly or visa-versa. Market share does affect our jobs and careers but there is a reason the language has been successful and will continue to be. A speed increase is not a magical bullet here, if that was the case and they wanted to use PHP they'd use HHVM or even Hack lang and change their usage. (Yes, there are other things there but come on, 99% of the time core PHP speed is not the issue.) Let's save the effort on this useless conversation, focus on driving SOMETHING forward, WHATEVER that may be and stop taking everything so damn personal. Regards, Mike On Sun, Jul 27, 2014 at 7:18 PM, Kris Craig kris.cr...@gmail.com wrote: On Sun, Jul 27, 2014 at 3:54 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Sun, Jul 27, 2014 at 5:03 PM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 09:26, Kris Craig kris.cr...@gmail.com wrote: On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote: Here's my question to counter yours, Michael: What's the rush? Every day php-ng is not GA, PHP is losing ground to its competitors. Umm, how? Do you have any data to support this? According to http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing. As far as our competitors are concerned, well: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python As you can see, PHP continues to dominate with over 80% market share and no signs-- at least, none that I can see-- that we are losing ground as you stated. Surely it's wise to make the same wrong assumptions Microsoft did with Internet Explorer? PHP is losing as a general scripting language for sure. JavaScript is winning in this area even if it was originated as a web client scripting language. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://langpop.com/ We are better to consider this situation seriously. IMHO. Focus on web as well as encourage general usage is what we need. Making PHP a choice for new project should be one of the most important objective. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net According to w3techs, JavaScript retains an extremely tiny market share in terms of general purpose languages: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js It looks like the sources are all measuring different metrics. It would be interesting to see a closer analysis of the data and figure out which metrics are the most relevant to this question. --Kris
[PHP-DEV] Re： [PHP-DEV] RFC: Move phpng to master
On 27 07 2014, at 11:44, Kris Craig kris.cr...@gmail.com (mailto:kris.cr...@gmail.com) wrote: [a lot] Maybe because you see those as competitors, but I see HHVM and friends as current competitors, being evaluated to replace stock PHP, which is definitely not covered by any nice statistics you can currently view. I can confirm that, wikimedia is migrating from PHP to HHVM, see: http://lists.wikimedia.org/pipermail/wikitech-l/2014-July/077690.html and I also have saw many friends talking about migrating from PHP to HHVM only for performance gain. Cheers, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Cheers, David Dai
Re: [PHP-DEV] RFC: Move phpng to master
On Fri, Jul 25, 2014 at 12:51 AM, Zeev Suraski z...@zend.com wrote: On Fri, Jul 25, 2014 at 7:28 AM, Kris Craig kris.cr...@gmail.com wrote: While this is a major change to the language implementation, it does not actually affect end users in any meaningful way except for the positive ‘side effect’ of their apps running faster. So while we believe that technically a 50%+1 vote should suffice, we hope to get well over 2/3. If you're not going to delay this, then you should at very least clarify the wording in this section. You believe 50%+1 should suffice but hope to get well over 2/3. So is the *required* majority 50%+1 or 2/3? The text I put there is exactly what I think about the subject of required majority. 50%+1 is enough for a change that does not effect end users in any meaningful way, but I'll be happier if it received a 2/3 majority to leave any doubts away. I should also point out that, according to the Voting RFC, whether or not an RFC actually affects end users in any meaningful way is NOT a factor in determining whether a 2/3 supermajority is required or not. Here's what it actually states: For these reasons, a feature affecting the language itself (new syntax for example) will be considered as 'accepted' if it wins a 2/3 of the votes. Other RFCs require 50% + 1 votes to get 'accepted'. Since the phpng RFC already acknowledges that it affects the language itself, this is clearly a 2/3 requirement situation. Whether it affects end-users or not is irrelevant. Under current rules, your RFC must have 2/3 support in order to pass. As the person who wrote that text in the Voting RFC, I can tell you with absolute certainty that you are 100% wrong in your interpretation, as I've said numerous times in the past. A feature that affects the *language* itself is not a feature that affects the *language implementation*. That may be what you meant, Zeev, but that's not what you wrote. As Jonny already pointed out, what you intended isn't relevant if it doesn't match the final wording you actually put in there. The Voting RFC doesn't say language implementation. It says language. That means, if it affects the language, it requires 2/3. Period. If you wanted it to have a more narrow definition, then why didn't you put it in there? It's just not making any sense to me. You might want to consider putting an amendment to the Voting RFC to a vote to clarify that language, but as it stands right now, any feature that affects the language itself-- regardless of userland impact-- requires a 2/3 vote. Saying, Well, that's not exactly what I meant, after the fact just isn't a convincing argument for me. Generally speaking, now that we have a Specification project, the spirit of the Voting RFC is that changes to the Language Specification would require 2/3 majority, while all other changes would not. This is also not 100% accurate since there are some elements of the language behavior that aren't covered by the spec (e.g.superglobal availability and behavior) - Again, I'd strongly suggest you propose new language for the Voting RFC to reflect these statements, because none of that is apparent in the current wording. but replacing the implementation with a compatible one absolutely does *not* fall within the realm of features that affect the language. I disagree. Whether or not the new stuff is compatible, it does directly affect the language. The PHPNG RFC itself even acknowledges that it affects the language. Furthermore, as far as the spirit of the Voting RFC is concerned, I seriously doubt it would be in the spirit of it to merge a massive overhaul of the codebase that will affect virtually all development with just a simple majority. It could be (and has been) argued that this will inevitably lead to userland changes. But again, whether it affects userland or not is completely irrelevant. The Voting RFC says-- whether you meant it to or not, it does say-- that 2/3 is required if it affects the language, period. It does not contain any exceptions for lessened impact on userland. If you recall the 64-bit discussion several months ago, when I was (back then) on the opposing side, I clearly said to people who said this requires a 2/3 majority that it's very debatable - because while it does have some end user impact that changes the language behavior, it's mostly an implementation issue, which as such requires a simple majority. So I'm both consistent, and not reinterpreting the rules to fit my needs. Fair enough. You have been consistent on this so I don't think anyone can reasonably accuse you of just trying to twist this to suit your needs. As such, I ask that you at least update the wording to make it clear that 2/3 *is* required for the RFC to pass in order to avoid confusion when it comes to a vote. I still think you should hold-off until these other issues of dispute are resolved, though. But that's your
RE: [PHP-DEV] RFC: Move phpng to master
Kris, I’ll make it short. EVERY RFC affects the language in *some* way – be it its features, positioning, perception, performance, implementation, testability, you name it. Each and every one, or we wouldn’t be discussing it on php.net’s internals@ mailing list. So I’m afraid I’m not going to use *your* interpretation for what the Voting RFC means (which in effect is either 2/3 majority for every RFC) – but rather, what I *know* is the meaning, and what is clearly the spirit of the RFC. Spirit I say? Here’s what I mean: *“**Given that changes to languages (as opposed to changes to apps or even frameworks) are for the most part irreversible”* Implementation improvements such as PHPNG are not irreversible. New features or changed features are. This deals with language features, that once we publish, we cannot take back as people already start using them. *“the purpose of the vote is to ensure that there's strong support for the proposed feature.”* Is PHPNG a feature? No, it’s not. It’s improvements performance optimizations at the implementation level. Those who have been following my involvement on internals@ over the years know my position about both feature creep and downwards compatibility, and I’m absolutely certain that it was clear to them – most if not all – what the meaning here was. That’s 100.0% irrelevant to PHPNG. FYI, I don’t intend to ping pong with you about it. I’ve said what I had to say about that topic. Zeev
Re: [PHP-DEV] RFC: Move phpng to master
On 26 Jul 2014, at 23:16, Zeev Suraski z...@zend.com wrote: *“**Given that changes to languages (as opposed to changes to apps or even frameworks) are for the most part irreversible”* Implementation improvements such as PHPNG are not irreversible. New features or changed features are. This deals with language features, that once we publish, we cannot take back as people already start using them. *“the purpose of the vote is to ensure that there's strong support for the proposed feature.”* Is PHPNG a feature? No, it’s not. It’s improvements performance optimizations at the implementation level. Those who have been following my involvement on internals@ over the years know my position about both feature creep and downwards compatibility, and I’m absolutely certain that it was clear to them – most if not all – what the meaning here was. That’s 100.0% irrelevant to PHPNG. For what it’s worth, I’d completely agree with Zeev here. phpng is really just an implementation deal, it doesn’t need a 2/3 vote, controversial or no. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
In that case tthe voting RFC should be improved. The sentence about 1/2 vs 2/3 votes is really ambiguous. Not fixing it will always lead to discussions over and over again. On Sun, Jul 27, 2014 at 12:32 AM, Andrea Faulds a...@ajf.me wrote: On 26 Jul 2014, at 23:16, Zeev Suraski z...@zend.com wrote: *“**Given that changes to languages (as opposed to changes to apps or even frameworks) are for the most part irreversible”* Implementation improvements such as PHPNG are not irreversible. New features or changed features are. This deals with language features, that once we publish, we cannot take back as people already start using them. *“the purpose of the vote is to ensure that there's strong support for the proposed feature.”* Is PHPNG a feature? No, it’s not. It’s improvements performance optimizations at the implementation level. Those who have been following my involvement on internals@ over the years know my position about both feature creep and downwards compatibility, and I’m absolutely certain that it was clear to them – most if not all – what the meaning here was. That’s 100.0% irrelevant to PHPNG. For what it’s worth, I’d completely agree with Zeev here. phpng is really just an implementation deal, it doesn’t need a 2/3 vote, controversial or no. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On 27/07/2014 00:32, Andrea Faulds wrote: Is PHPNG a feature? No, it’s not. It’s improvements performance optimizations at the implementation level. Those who have been following my involvement on internals@ over the years know my position about both feature creep and downwards compatibility, and I’m absolutely certain that it was clear to them – most if not all – what the meaning here was. That’s 100.0% irrelevant to PHPNG. For what it’s worth, I’d completely agree with Zeev here. phpng is really just an implementation deal, it doesn’t need a 2/3 vote, controversial or no. I agree about the meaning and the fact that phpng is implementation. However if there is some userland BC break, then it should effectively be 2/3, shouldn't it? How about the Incompatibilities (made on purpose and are not going to be fixed)? Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Sat, Jul 26, 2014 at 3:16 PM, Zeev Suraski z...@zend.com wrote:
Kris,
I’ll make it short.
EVERY RFC affects the language in *some* way – be it its features,
positioning, perception, performance, implementation, testability, you name
it.
I believe that argument is specious. The RFC says, a feature
affecting the language *itself* (emphasis mine). A feature that affects
performance need not necessarily affect the language itself. For example,
an RFC to add an APXS configuration option to the configure script would
have no impact on the language itself, even though it technically involves
a modified implementation and testing scenario. And affecting people's
perception of PHP most certainly does not constitute a feature that
affects the language itself, unless you're making a quantum theory argument
wherein the mere act of observing something alters its state.
Finally, here's an example from your RFC of how it *directly* impacts the
language itself:
PHPNG doesn't keep original values of arguments passed to user functions,
so func_get_arg() and func_get_args() will return current value of argument
instead of the actually passed. The following code is going to be affected
“function foo($x) { $x = 2; return func_get_arg(0);} var_dump(foo(1));”
Function parameters with duplicate name are not allowed anymore.
Definitions like “function foo($x,$x) {}” will lead to compile time error
“Redefinition of parameter”
So even IF you want to reduce the scope of the 2/3 requirement to language
impacts in userland only, your RFC *still* falls under that requirement
because it directly affects the language itself in userland, as described
above. I would again invite you to reconsider your position on this and
avoid a protracted fight on this that would only serve to split the
community.
--Kris
Re: [PHP-DEV] RFC: Move phpng to master
On 27 Jul 2014, at 01:53, Kris Craig kris.cr...@gmail.com wrote:
so func_get_arg() and func_get_args() will return current value of argument
instead of the actually passed. The following code is going to be affected
“function foo($x) { $x = 2; return func_get_arg(0);} var_dump(foo(1));”
Those are to be considered functions, not language features.
Function parameters with duplicate name are not allowed anymore.
Definitions like “function foo($x,$x) {}” will lead to compile time error
“Redefinition of parameter”
While that’s *technically* a language change, such code doesn’t work properly
anyway.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
We didn't care about versions while it was a separate branch. Changing to ZEND_ENGINE_3 makes full sense from my point of view. Thanks. Dmitry. On Fri, Jul 25, 2014 at 7:47 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Zeev, On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski z...@zend.com wrote: The RFC is available at https://wiki.php.net/rfc/phpng Some supporting links available down below. Comments welcome! It says Zend2 in zend.h 25 #define ZEND_VERSION 2.7.0-dev 26 27 #define ZEND_ENGINE_2 Isn't it better named Zend3? It may be changed anytime, though. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: Move phpng to master
On Fri, Jul 25, 2014 at 7:28 AM, Kris Craig kris.cr...@gmail.com wrote: While this is a major change to the language implementation, it does not actually affect end users in any meaningful way except for the positive ‘side effect’ of their apps running faster. So while we believe that technically a 50%+1 vote should suffice, we hope to get well over 2/3. If you're not going to delay this, then you should at very least clarify the wording in this section. You believe 50%+1 should suffice but hope to get well over 2/3. So is the *required* majority 50%+1 or 2/3? The text I put there is exactly what I think about the subject of required majority. 50%+1 is enough for a change that does not effect end users in any meaningful way, but I'll be happier if it received a 2/3 majority to leave any doubts away. I should also point out that, according to the Voting RFC, whether or not an RFC actually affects end users in any meaningful way is NOT a factor in determining whether a 2/3 supermajority is required or not. Here's what it actually states: For these reasons, a feature affecting the language itself (new syntax for example) will be considered as 'accepted' if it wins a 2/3 of the votes. Other RFCs require 50% + 1 votes to get 'accepted'. Since the phpng RFC already acknowledges that it affects the language itself, this is clearly a 2/3 requirement situation. Whether it affects end-users or not is irrelevant. Under current rules, your RFC must have 2/3 support in order to pass. As the person who wrote that text in the Voting RFC, I can tell you with absolute certainty that you are 100% wrong in your interpretation, as I've said numerous times in the past. A feature that affects the *language* itself is not a feature that affects the *language implementation*. Generally speaking, now that we have a Specification project, the spirit of the Voting RFC is that changes to the Language Specification would require 2/3 majority, while all other changes would not. This is also not 100% accurate since there are some elements of the language behavior that aren't covered by the spec (e.g.superglobal availability and behavior) - but replacing the implementation with a compatible one absolutely does *not* fall within the realm of features that affect the language. If you recall the 64-bit discussion several months ago, when I was (back then) on the opposing side, I clearly said to people who said this requires a 2/3 majority that it's very debatable - because while it does have some end user impact that changes the language behavior, it's mostly an implementation issue, which as such requires a simple majority. So I'm both consistent, and not reinterpreting the rules to fit my needs. As such, I ask that you at least update the wording to make it clear that 2/3 *is* required for the RFC to pass in order to avoid confusion when it comes to a vote. I still think you should hold-off until these other issues of dispute are resolved, though. But that's your choice. I simply ask that you fix the required majority section to make it in compliance with current voting rules. I updated the section to be fully technical and removed my wish of heart to get a 2/3 majority. Although I'd still very much like to get 2/3, it's not required. Zeev
RE: [PHP-DEV] RFC: Move phpng to master
Maybe we should wait to see if PHP 7 gets chosen and jump to ZEND_ENGINE_4? J Another option would be to simply align the version number with that of PHP. The separate version number dates back to 1999 where we thought we may put this language engine into projects other than PHP, but I think it’s safe to say that if we didn’t get around to it until now, it’s probably not going to happen in the future… BTW, the only reason it’s 2.7 is because the PHP version there is presently 5.7. Zeev *From:* Dmitry Stogov [mailto:dmi...@zend.com] *Sent:* Friday, July 25, 2014 10:23 AM *To:* Yasuo Ohgaki *Cc:* Zeev Suraski; PHP internals *Subject:* Re: [PHP-DEV] RFC: Move phpng to master We didn't care about versions while it was a separate branch. Changing to ZEND_ENGINE_3 makes full sense from my point of view. Thanks. Dmitry. On Fri, Jul 25, 2014 at 7:47 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Zeev, On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski z...@zend.com wrote: The RFC is available at https://wiki.php.net/rfc/phpng Some supporting links available down below. Comments welcome! It says Zend2 in zend.h 25 #define ZEND_VERSION 2.7.0-dev 26 27 #define ZEND_ENGINE_2 Isn't it better named Zend3? It may be changed anytime, though. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: Move phpng to master
On Fri, Jul 25, 2014 at 9:51 AM, Zeev Suraski z...@zend.com wrote: On Fri, Jul 25, 2014 at 7:28 AM, Kris Craig kris.cr...@gmail.com wrote: While this is a major change to the language implementation, it does not actually affect end users in any meaningful way except for the positive ‘side effect’ of their apps running faster. So while we believe that technically a 50%+1 vote should suffice, we hope to get well over 2/3. If you're not going to delay this, then you should at very least clarify the wording in this section. You believe 50%+1 should suffice but hope to get well over 2/3. So is the *required* majority 50%+1 or 2/3? The text I put there is exactly what I think about the subject of required majority. 50%+1 is enough for a change that does not effect end users in any meaningful way, but I'll be happier if it received a 2/3 majority to leave any doubts away. It affects users, it is a total rewamp of the engine, it requires 2/3. I fail to understand to see yet another attempt to discard simple RFC rules. I should also point out that, according to the Voting RFC, whether or not an RFC actually affects end users in any meaningful way is NOT a factor in determining whether a 2/3 supermajority is required or not. Here's what it actually states: For these reasons, a feature affecting the language itself (new syntax for example) will be considered as 'accepted' if it wins a 2/3 of the votes. Other RFCs require 50% + 1 votes to get 'accepted'. Since the phpng RFC already acknowledges that it affects the language itself, this is clearly a 2/3 requirement situation. Whether it affects end-users or not is irrelevant. Under current rules, your RFC must have 2/3 support in order to pass. As the person who wrote that text in the Voting RFC, I can tell you with absolute certainty that you are 100% wrong in your interpretation, as I've said numerous times in the past. A feature that affects the *language* itself is not a feature that affects the *language implementation*. It affects both, there is no point to argue. I updated the section to be fully technical and removed my wish of heart to get a 2/3 majority. Although I'd still very much like to get 2/3, it's not required. It is. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
2014.07.25. 9:52, Zeev Suraski z...@zend.com ezt írta: On Fri, Jul 25, 2014 at 7:28 AM, Kris Craig kris.cr...@gmail.com wrote: While this is a major change to the language implementation, it does not actually affect end users in any meaningful way except for the positive ‘side effect’ of their apps running faster. So while we believe that technically a 50%+1 vote should suffice, we hope to get well over 2/3. If you're not going to delay this, then you should at very least clarify the wording in this section. You believe 50%+1 should suffice but hope to get well over 2/3. So is the *required* majority 50%+1 or 2/3? The text I put there is exactly what I think about the subject of required majority. 50%+1 is enough for a change that does not effect end users in any meaningful way, but I'll be happier if it received a 2/3 majority to leave any doubts away. I should also point out that, according to the Voting RFC, whether or not an RFC actually affects end users in any meaningful way is NOT a factor in determining whether a 2/3 supermajority is required or not. Here's what it actually states: For these reasons, a feature affecting the language itself (new syntax for example) will be considered as 'accepted' if it wins a 2/3 of the votes. Other RFCs require 50% + 1 votes to get 'accepted'. Since the phpng RFC already acknowledges that it affects the language itself, this is clearly a 2/3 requirement situation. Whether it affects end-users or not is irrelevant. Under current rules, your RFC must have 2/3 support in order to pass. As the person who wrote that text in the Voting RFC, I can tell you with absolute certainty that you are 100% wrong in your interpretation, as I've said numerous times in the past. A feature that affects the *language* itself is not a feature that affects the *language implementation*. hi, I'm not really following the phpng development that closely, but afaik it does have some userland impact (the change for using the same argument name in a function signature multiple times and the change in func_get_args() comes into mind). We also discussed before that major breakage in the extension api would also warrant a 2/3 vote, but it seems that you disagree with that. My last argument is, that given that we allow anybody with a php.net account to vote on Zend Engine changes, we are always safer with the 2/3 vote. That way the worst thing that can happen is something not getting into, but the authors can try again (after fixing the cause of the no votes), but with simple majority it would be rather easy to force something into the language, even if all of the active Zend maintainers vote no because it is a horrible design decision or has a crappy implementation. just my 2 cents ofc.
Re: [PHP-DEV] RFC: Move phpng to master
Hi Zeev, Now we're into arguing semantics of the Voting RFC. Whether you meant something else when you wrote that is now irrelevant, it's what is written that is the rule, not somebodies individual interpretation surely? In any meaning full way are your words, not what the accepted RFC states. From what's been said previously, the changes in NG are strictly implementation changes, i.e. syntax etc remains the same throughout. That's great, and would require a 50%+1 for vote as far as I can see. However. If there are /any/ changes to what end-users would see, that is by definition a change in the language, no matter how small (or meaningless), you are into 2/3 majority territory. So, can those who have worked on it confirm with a simple yes / no, are there changes (right now) that may affect users. Second, if the answer is no, is there somebody that can review and confirm that this is the case that hasn't worked on NG preferably (not because of trust, just because it's a large changeset which makes it easy to miss stuff and a fresh pair of eyes is good). Now. If yes, 2/3 majority is required. It's as simple as that. If no, then I would suggest starting the review to confirm. I would hope that the remaining time in the 2 weeks would be enough to accomplish a review, but somebody correct me if they think otherwise, so the vote start / end should hopefully be unaffected beyond vote requirements. Cheers. Jonny.
Re: [PHP-DEV] RFC: Move phpng to master
Hi, I didn't see any phpng related discussion for a day. If we have nothing to discuss, may be we should just the start a voting process. :) It's not a problem for me to wait a week or even month. I just like to know. if anyone thinks, that we have any stoppers to start the voting. Last days we tried to improve https://wiki.php.net/phpng-upgrading However, our English is poor and boring. It would be cool, if native speakers would improve the docs. (section related to Objects is not ready yet). Thanks. Dmitry. On Thu, Jul 24, 2014 at 12:27 AM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Wednesday, July 23, 2014 8:00 AM To: Zeev Suraski; PHP internals Subject: Re: [PHP-DEV] RFC: Move phpng to master I think before we do that we need to do much better documentation around the changes in the engine. I know that in the past we followed the code is documentation pattern, but the code there becomes more and more dense, with macros upon macros upon macros, and myriads of micro-optimizations which make sense only in specific context. Absent that context and documentation, understanding what is going on becomes much harder and so becomes dealing with that code. Some of the changes right now are partially documented in https://wiki.php.net/phpng-int, some (like parameter parsing API) not documented at all. Given that, I'm not even sure I understand what phpng is right now - as I didn't have time to parse every commit during active development. So it would be nice to have some internal docs if we want people to form an informed opinion about what is being proposed. And, of course, the porting guide for extension authors is another required part. I know the phpng team did great work porting the extensions, but people would need to support them and add the new ones, so it is a must. As Dmitry mentioned, this is something we're going to work on (with primary focus around the porting guide, and secondary focus on extending the internals document). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
The the before start is a mistake :) On Thu, Jul 24, 2014 at 11:04 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, I didn't see any phpng related discussion for a day. If we have nothing to discuss, may be we should just the start a voting process. :) It's not a problem for me to wait a week or even month. I just like to know. if anyone thinks, that we have any stoppers to start the voting. Last days we tried to improve https://wiki.php.net/phpng-upgrading However, our English is poor and boring. It would be cool, if native speakers would improve the docs. (section related to Objects is not ready yet). Thanks. Dmitry. On Thu, Jul 24, 2014 at 12:27 AM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Wednesday, July 23, 2014 8:00 AM To: Zeev Suraski; PHP internals Subject: Re: [PHP-DEV] RFC: Move phpng to master I think before we do that we need to do much better documentation around the changes in the engine. I know that in the past we followed the code is documentation pattern, but the code there becomes more and more dense, with macros upon macros upon macros, and myriads of micro-optimizations which make sense only in specific context. Absent that context and documentation, understanding what is going on becomes much harder and so becomes dealing with that code. Some of the changes right now are partially documented in https://wiki.php.net/phpng-int, some (like parameter parsing API) not documented at all. Given that, I'm not even sure I understand what phpng is right now - as I didn't have time to parse every commit during active development. So it would be nice to have some internal docs if we want people to form an informed opinion about what is being proposed. And, of course, the porting guide for extension authors is another required part. I know the phpng team did great work porting the extensions, but people would need to support them and add the new ones, so it is a must. As Dmitry mentioned, this is something we're going to work on (with primary focus around the porting guide, and secondary focus on extending the internals document). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
hi Dmitry, On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, I didn't see any phpng related discussion for a day. If we have nothing to discuss, may be we should just the start a voting process. :) It's not a problem for me to wait a week or even month. I just like to know. if anyone thinks, that we have any stoppers to start the voting. Last days we tried to improve https://wiki.php.net/phpng-upgrading However, our English is poor and boring. It would be cool, if native speakers would improve the docs. (section related to Objects is not ready yet). The current status of the doc, migration guide, list of changes and explanation will force me to vote -1 at this point. I am very reluctant to give you a blank card and then keep hearing no to every 2nd patch we will provide :) Also none of my questions have been answered in the various phpng threads, so it is not like I can vote +1 anyway... Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
Vote -1, I won't be surprised. I'm asking if we have any stoppers to start the voting, if we have nothing to discuss. The porting guide is almost ready now, but it never be 100% ready to someones. Thanks. Dmitry. On Thu, Jul 24, 2014 at 11:14 PM, Pierre Joye pierre@gmail.com wrote: hi Dmitry, On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, I didn't see any phpng related discussion for a day. If we have nothing to discuss, may be we should just the start a voting process. :) It's not a problem for me to wait a week or even month. I just like to know. if anyone thinks, that we have any stoppers to start the voting. Last days we tried to improve https://wiki.php.net/phpng-upgrading However, our English is poor and boring. It would be cool, if native speakers would improve the docs. (section related to Objects is not ready yet). The current status of the doc, migration guide, list of changes and explanation will force me to vote -1 at this point. I am very reluctant to give you a blank card and then keep hearing no to every 2nd patch we will provide :) Also none of my questions have been answered in the various phpng threads, so it is not like I can vote +1 anyway... Cheers, -- Pierre @pierrejoye | http://www.libgd.org
Re: [PHP-DEV] RFC: Move phpng to master
On Jul 24, 2014 9:45 PM, Dmitry Stogov dmi...@zend.com wrote: Vote -1, I won't be surprised. I'm asking if we have any stoppers to start the voting, if we have nothing to discuss. The porting guide is almost ready now, but it never be 100% ready to someones. It is the stopper and not only the migration guide. We need to know what has been done to do an informed vote. We also need to know what else is coming, readiness for changes etc. Voting now means giving you a blank card and simply accept anything and expose us to what already happened too many times, rejecting patches with no good reasons. Thanks. Dmitry. On Thu, Jul 24, 2014 at 11:14 PM, Pierre Joye pierre@gmail.com wrote: hi Dmitry, On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, I didn't see any phpng related discussion for a day. If we have nothing to discuss, may be we should just the start a voting process. :) It's not a problem for me to wait a week or even month. I just like to know. if anyone thinks, that we have any stoppers to start the voting. Last days we tried to improve https://wiki.php.net/phpng-upgrading However, our English is poor and boring. It would be cool, if native speakers would improve the docs. (section related to Objects is not ready yet). The current status of the doc, migration guide, list of changes and explanation will force me to vote -1 at this point. I am very reluctant to give you a blank card and then keep hearing no to every 2nd patch we will provide :) Also none of my questions have been answered in the various phpng threads, so it is not like I can vote +1 anyway... Cheers, -- Pierre @pierrejoye | http://www.libgd.org
Re: [PHP-DEV] RFC: Move phpng to master
On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, I didn't see any phpng related discussion for a day. If we have nothing to discuss, may be we should just the start a voting process. :) It's not a problem for me to wait a week or even month. I just like to know. if anyone thinks, that we have any stoppers to start the voting. Last days we tried to improve https://wiki.php.net/phpng-upgrading However, our English is poor and boring. It would be cool, if native speakers would improve the docs. (section related to Objects is not ready yet). Our voting RFC prescribes that voting can start no earlier than two weeks after the RFC announcement (which was three days ago). As this is a big change and there's no particular rush to get this merged, I'd suggest to stick with the usual process :) Nikita
Re: [PHP-DEV] RFC: Move phpng to master
You talk not about starting the voting, you talk about your opinion. Anyway. No problem I can wait another week and start the voting according to all the rules. Dmitry. On Thu, Jul 24, 2014 at 11:55 PM, Pierre Joye pierre@gmail.com wrote: On Jul 24, 2014 9:45 PM, Dmitry Stogov dmi...@zend.com wrote: Vote -1, I won't be surprised. I'm asking if we have any stoppers to start the voting, if we have nothing to discuss. The porting guide is almost ready now, but it never be 100% ready to someones. It is the stopper and not only the migration guide. We need to know what has been done to do an informed vote. We also need to know what else is coming, readiness for changes etc. Voting now means giving you a blank card and simply accept anything and expose us to what already happened too many times, rejecting patches with no good reasons. Thanks. Dmitry. On Thu, Jul 24, 2014 at 11:14 PM, Pierre Joye pierre@gmail.com wrote: hi Dmitry, On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, I didn't see any phpng related discussion for a day. If we have nothing to discuss, may be we should just the start a voting process. :) It's not a problem for me to wait a week or even month. I just like to know. if anyone thinks, that we have any stoppers to start the voting. Last days we tried to improve https://wiki.php.net/phpng-upgrading However, our English is poor and boring. It would be cool, if native speakers would improve the docs. (section related to Objects is not ready yet). The current status of the doc, migration guide, list of changes and explanation will force me to vote -1 at this point. I am very reluctant to give you a blank card and then keep hearing no to every 2nd patch we will provide :) Also none of my questions have been answered in the various phpng threads, so it is not like I can vote +1 anyway... Cheers, -- Pierre @pierrejoye | http://www.libgd.org
Re: [PHP-DEV] RFC: Move phpng to master
agree, I just don't see any blockers, except for Pierre. Lets wait a week. Thanks, Dmitry. On Fri, Jul 25, 2014 at 12:01 AM, Nikita Popov nikita@gmail.com wrote: On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov dmi...@zend.com wrote: Hi, I didn't see any phpng related discussion for a day. If we have nothing to discuss, may be we should just the start a voting process. :) It's not a problem for me to wait a week or even month. I just like to know. if anyone thinks, that we have any stoppers to start the voting. Last days we tried to improve https://wiki.php.net/phpng-upgrading However, our English is poor and boring. It would be cool, if native speakers would improve the docs. (section related to Objects is not ready yet). Our voting RFC prescribes that voting can start no earlier than two weeks after the RFC announcement (which was three days ago). As this is a big change and there's no particular rush to get this merged, I'd suggest to stick with the usual process :) Nikita
Re: [PHP-DEV] RFC: Move phpng to master
On Jul 24, 2014 10:13 PM, Dmitry Stogov dmi...@zend.com wrote: agree, I just don't see any blockers, except for Pierre. Come on Dmitry, I am not the only who has asked that.
Re: [PHP-DEV] RFC: Move phpng to master
one week - two weeks - months - years. I'll wait. I know what I'm doing. I'll make it. Dmitry. On Fri, Jul 25, 2014 at 12:26 AM, Pierre Joye pierre@gmail.com wrote: On Jul 24, 2014 10:13 PM, Dmitry Stogov dmi...@zend.com wrote: agree, I just don't see any blockers, except for Pierre. Come on Dmitry, I am not the only who has asked that.
Re: [PHP-DEV] RFC: Move phpng to master
On Thu, Jul 24, 2014 at 1:37 PM, Dmitry Stogov dmi...@zend.com wrote: one week - two weeks - months - years. I'll wait. I know what I'm doing. I'll make it. Dmitry. On Fri, Jul 25, 2014 at 12:26 AM, Pierre Joye pierre@gmail.com wrote: On Jul 24, 2014 10:13 PM, Dmitry Stogov dmi...@zend.com wrote: agree, I just don't see any blockers, except for Pierre. Come on Dmitry, I am not the only who has asked that. Just to throw in my usual two-cents, it seems to me that this RFC is very premature. It's the same sort of over-eagerness I saw in the front-page news post a few weeks back. I understand what you guys are trying to accomplish and I applaud you for it, but as far as I can see, it's still quite a ways away from being ready for prime time. And yet, you seem to be acting like it's already there. Aside from the code needing to be ready/tested, you also need to have a more matured collaboration with community folks outside your project like Pierre, which at the moment appears to be downright hostile. Even if the code looked great and everything else was in place, I would never vote to switch over to such a drastic new schema when there's this much animosity and controversy surrounding it. I keep reading complaints about questions being ignored and conflicting stories about secrecy and process. I also think there's some merit to the concern raised about the ambiguity being a prelude to patches being rejected over trivial concerns. I think you guys need to slow down and mend a few fences if you want to make this happen. As much as I like the goals of this project, I'm forced to vote -1 for now, as well. I just think you're jumping the gun when there are too many unanswered questions/concerns still out there. --Kris
Re: [PHP-DEV] RFC: Move phpng to master
any one may vote according to their thoughts I'm not going to persuade any one. I already know the opinion of the majority. Unfortunately, now many people lessen to the guys who speaks a lot. I was never able to do it :), but ... look into results we provide. They are more expressive than any words. Thanks. Dmitry, On Fri, Jul 25, 2014 at 1:39 AM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 24, 2014 at 1:37 PM, Dmitry Stogov dmi...@zend.com wrote: one week - two weeks - months - years. I'll wait. I know what I'm doing. I'll make it. Dmitry. On Fri, Jul 25, 2014 at 12:26 AM, Pierre Joye pierre@gmail.com wrote: On Jul 24, 2014 10:13 PM, Dmitry Stogov dmi...@zend.com wrote: agree, I just don't see any blockers, except for Pierre. Come on Dmitry, I am not the only who has asked that. Just to throw in my usual two-cents, it seems to me that this RFC is very premature. It's the same sort of over-eagerness I saw in the front-page news post a few weeks back. I understand what you guys are trying to accomplish and I applaud you for it, but as far as I can see, it's still quite a ways away from being ready for prime time. And yet, you seem to be acting like it's already there. Aside from the code needing to be ready/tested, you also need to have a more matured collaboration with community folks outside your project like Pierre, which at the moment appears to be downright hostile. Even if the code looked great and everything else was in place, I would never vote to switch over to such a drastic new schema when there's this much animosity and controversy surrounding it. I keep reading complaints about questions being ignored and conflicting stories about secrecy and process. I also think there's some merit to the concern raised about the ambiguity being a prelude to patches being rejected over trivial concerns. I think you guys need to slow down and mend a few fences if you want to make this happen. As much as I like the goals of this project, I'm forced to vote -1 for now, as well. I just think you're jumping the gun when there are too many unanswered questions/concerns still out there. --Kris
Re: [PHP-DEV] RFC: Move phpng to master
Dmitry Stogov in php.internals (Fri, 25 Jul 2014 02:09:53 +0400): I already know the opinion of the majority. Do you also know the opinion of 2/3 of the voters? Jan (without voting right BTW) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On 25 ביול 2014, at 01:35, Jan Ehrhardt php...@ehrhardt.nl wrote: Dmitry Stogov in php.internals (Fri, 25 Jul 2014 02:09:53 +0400): I already know the opinion of the majority. Do you also know the opinion of 2/3 of the voters? Guys, Let's deescalate here. Dmitry is understandably quite attached to this -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Thu, Jul 24, 2014 at 3:39 PM, Zeev Suraski z...@zend.com wrote: On 25 ביול 2014, at 01:35, Jan Ehrhardt php...@ehrhardt.nl wrote: Dmitry Stogov in php.internals (Fri, 25 Jul 2014 02:09:53 +0400): I already know the opinion of the majority. Do you also know the opinion of 2/3 of the voters? Guys, Let's deescalate here. Dmitry is understandably quite attached to this Very much agreed! I'd love to see cooler heads prevail on this. I see no reason why both sides can't come together on this if they'd just drop all this posturing. Supporters should slow down and take the time to answer questions and build consensus. Critics should remember that these guys have put a lot of work into it and are understandably eager to see it come to fruition. I think that would make this a much more constructive, much less melodramatic process. And I'd certainly be inclined to vote in favor of it once it's no longer a matter of heated controversy. =) --Kris
Re: [PHP-DEV] RFC: Move phpng to master
On 25 ביול 2014, at 01:35, Jan Ehrhardt php...@ehrhardt.nl wrote: Dmitry Stogov in php.internals (Fri, 25 Jul 2014 02:09:53 +0400): I already know the opinion of the majority. Do you also know the opinion of 2/3 of the voters? Guys, Let's deescalate here. Dmitry is understandably quite emotionally attached to this. I probably wouldn't have sent the emails he sent tonight on this thread had I been him - but I'm not... I agree with Nikita - there's no reason to shorten the mandatory 2wk cycle and I'd reply with no had others not beat me to it. I'd be highly annoyed if it was done to me on an RFC I care about. That said, I completely disagree with the delayers, who also happen to be ones who have a repeated tendency to talk a lot more than they do. Dmitry is one if the biggest php.net doers - and us can understand how it runs him the wrong way. The main missing piece was docs, and we made some progress there - but probably need some more time for people to provide feedback and adjust. Other than that I see absolutely no reason to stall beyond the 2wk discussion period, and every reason to floor the has pedal. I don't know what the voting outcome would be, but as I wrote in the RFC - I hope it will be well above 2/3, so that we have an awesome engine to match the shiny new version number :) Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
Hi Dmitry, On 25 Jul, 2014, at 6:09 am, Dmitry Stogov dmi...@zend.com wrote: any one may vote according to their thoughts I'm not going to persuade any one. I already know the opinion of the majority. Unfortunately, now many people lessen to the guys who speaks a lot. I was never able to do it :), but ... look into results we provide. They are more expressive than any words. First of all, kudos for all the hard you and the team have been putting into this :) From a developer’s point of view it would be nice to see a write-up of some of the changes that were made to the API's; I’m currently aware of the array (hash) API changes which are definitely an improvement over the old one, but there may be more that could also use an “idiom conversion guide”. Thanks. Dmitry, On Fri, Jul 25, 2014 at 1:39 AM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 24, 2014 at 1:37 PM, Dmitry Stogov dmi...@zend.com wrote: one week - two weeks - months - years. I'll wait. I know what I'm doing. I'll make it. Dmitry. On Fri, Jul 25, 2014 at 12:26 AM, Pierre Joye pierre@gmail.com wrote: On Jul 24, 2014 10:13 PM, Dmitry Stogov dmi...@zend.com wrote: agree, I just don't see any blockers, except for Pierre. Come on Dmitry, I am not the only who has asked that. Just to throw in my usual two-cents, it seems to me that this RFC is very premature. It's the same sort of over-eagerness I saw in the front-page news post a few weeks back. I understand what you guys are trying to accomplish and I applaud you for it, but as far as I can see, it's still quite a ways away from being ready for prime time. And yet, you seem to be acting like it's already there. Aside from the code needing to be ready/tested, you also need to have a more matured collaboration with community folks outside your project like Pierre, which at the moment appears to be downright hostile. Even if the code looked great and everything else was in place, I would never vote to switch over to such a drastic new schema when there's this much animosity and controversy surrounding it. I keep reading complaints about questions being ignored and conflicting stories about secrecy and process. I also think there's some merit to the concern raised about the ambiguity being a prelude to patches being rejected over trivial concerns. I think you guys need to slow down and mend a few fences if you want to make this happen. As much as I like the goals of this project, I'm forced to vote -1 for now, as well. I just think you're jumping the gun when there are too many unanswered questions/concerns still out there. --Kris Best, Tjerk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Fri, Jul 25, 2014 at 12:51 AM, Zeev Suraski z...@zend.com wrote: That said, I completely disagree with the delayers, who also happen to be ones who have a repeated tendency to talk a lot more than they do. Dmitry is one if the biggest php.net doers - and us can understand how it runs him the wrong way. Excuse me? As one of the delayers, we do a shit load of work and I was one of the 1st to contribute to phpng, code and doc, before giving up because of the constant moving and lack of sync possibility. I never said that Dmitry does nothing or bad work. But rushing this RFC, even if you may get it accepted, is a strategic mistake. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
Hi Zeev, On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski z...@zend.com wrote: The RFC is available at https://wiki.php.net/rfc/phpng Some supporting links available down below. Comments welcome! It says Zend2 in zend.h 25 #define ZEND_VERSION 2.7.0-dev 26 27 #define ZEND_ENGINE_2 Isn't it better named Zend3? It may be changed anytime, though. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: Move phpng to master
On Thu, Jul 24, 2014 at 8:47 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Zeev, On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski z...@zend.com wrote: The RFC is available at https://wiki.php.net/rfc/phpng Some supporting links available down below. Comments welcome! While this is a major change to the language implementation, it does not actually affect end users in any meaningful way except for the positive ‘side effect’ of their apps running faster. So while we believe that technically a 50%+1 vote should suffice, we hope to get well over 2/3. If you're not going to delay this, then you should at very least clarify the wording in this section. You believe 50%+1 should suffice but hope to get well over 2/3. So is the *required* majority 50%+1 or 2/3? I should also point out that, according to the Voting RFC, whether or not an RFC actually affects end users in any meaningful way is NOT a factor in determining whether a 2/3 supermajority is required or not. Here's what it actually states: For these reasons, a feature affecting the language itself (new syntax for example) will be considered as 'accepted' if it wins a 2/3 of the votes. Other RFCs require 50% + 1 votes to get 'accepted'. Since the phpng RFC already acknowledges that it affects the language itself, this is clearly a 2/3 requirement situation. Whether it affects end-users or not is irrelevant. Under current rules, your RFC must have 2/3 support in order to pass. As such, I ask that you at least update the wording to make it clear that 2/3 *is* required for the RFC to pass in order to avoid confusion when it comes to a vote. I still think you should hold-off until these other issues of dispute are resolved, though. But that's your choice. I simply ask that you fix the required majority section to make it in compliance with current voting rules. --Kris
Re: [PHP-DEV] RFC: Move phpng to master
On Fri, Jul 25, 2014 at 6:28 AM, Kris Craig kris.cr...@gmail.com wrote: While this is a major change to the language implementation, it does not actually affect end users in any meaningful way except for the positive ‘side effect’ of their apps running faster. So while we believe that technically a 50%+1 vote should suffice, we hope to get well over 2/3. 2/3 is required, there is no doubt about it. That being said, I think we should block this RFC as it is by far one of the poorest one from a content point of view (referring to the RFC itself here). phpng is a huge change, or better said a huge set of huge changes. Even the php-next version number RFC has more details that this one. This is disturbing. The various document should be linked or merged (docs relevant directly to this rfc should be merged, link to https://wiki.php.net/phpng-upgrading is missing too. I can help with these steps next week. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Move phpng to master
-Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Wednesday, July 23, 2014 8:00 AM To: Zeev Suraski; PHP internals Subject: Re: [PHP-DEV] RFC: Move phpng to master I think before we do that we need to do much better documentation around the changes in the engine. I know that in the past we followed the code is documentation pattern, but the code there becomes more and more dense, with macros upon macros upon macros, and myriads of micro-optimizations which make sense only in specific context. Absent that context and documentation, understanding what is going on becomes much harder and so becomes dealing with that code. Some of the changes right now are partially documented in https://wiki.php.net/phpng-int, some (like parameter parsing API) not documented at all. Given that, I'm not even sure I understand what phpng is right now - as I didn't have time to parse every commit during active development. So it would be nice to have some internal docs if we want people to form an informed opinion about what is being proposed. And, of course, the porting guide for extension authors is another required part. I know the phpng team did great work porting the extensions, but people would need to support them and add the new ones, so it is a must. As Dmitry mentioned, this is something we're going to work on (with primary focus around the porting guide, and secondary focus on extending the internals document). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
Pierre, I don't replay to you, because it's bad for my health. Many people here would agree with me. I prefer to do things instead of endlessly repeated words. According to PHPNG - we set one big goal (performance), and worked on it really hard. Now everyone may see the result. It's just not possible to solve all the goals at once and we didn't try to do it. Big PHP users just can't not to care about performance, because it's money. I know most of them already experimented with HHVM. If we don't provide adequate replay, we may turn back into the language for home pages. Thanks. Dmitry. On Tue, Jul 22, 2014 at 6:58 AM, Pierre Joye pierre@gmail.com wrote: hi, On Tue, Jul 22, 2014 at 3:42 AM, Xinchen Hui larue...@gmail.com wrote: https://wiki.php.net/rfc/uniform_variable_syntax https://wiki.php.net/rfc/size_t_and_int64_next aren't they discussed and voted? what do you mean by we can't even start in previous comment? The int64 yes, that means and it is/was not possible given the status of phpng in the last weeks, way too many huge changes. Or you suggest we stop the current work to waiting them come their self? I'm saying that we should resolve the current situation where people can't work on stuff which would target php-next, because it is still a moving target. why Nikita could work on it? why me can work on it? Who is asking you to work on that? I'm saying that it is pretty unfortunate that we have to decide to between reviewing/accepting a huuuge chunk of changes or rejecting a significant performance boost and some api cleanup. we shouldn't, at least most people here shouldn't, only the guys who need to maintain them should. Yes and no. phpng, as a whole, as it was done, as it is done, and as it is proposed forces us to this choice. I have asked very early (later on that) about your plans, and it was told it will not be the base for php-next and its aim is not to replace master. I expressed doubts, I see now that I was right. I'm saying that we should stop pushing our own agendas, and figure out the best possible solution for the current situation, so that we can go forward with the development with the normal workflow, where everybody is on the same page, controversial changes are done through RFCs and we don't block each other from the work. you know what? I really don't like we should; we must, they means nothing.. They mean a lot, really a lot. I have spent lots of my time to work on PHP/PHPNG, more than 80 hours per month. Oh very nice. Now what do you think we spend on the int64 patch? While you were saying that it is fine for master but rejecting it later on because of your secret work on phpng? I really do not like that. I treat it like a regular work, dmitry spends more than me(8 hours per day). you ask me to stop to wait somebody who even can not work hours a month here? It is called team work, with full time developers (very few) and other contributors, doing work on php in their free time (the waste majority). We have to respect the latter much more, much much more. with all my respects: I really upset by people who always told you, hey man, don't be rush... Nobody tells you not to rush to work on a given feature. However many did, and I'd to tell it again: do not to rush on pushing the next major release. The version we (all) have to maintain for the next decade. And by maintain it is not only about the core, it is about its extensions, be in core extensions and in PECL or other areas. A bad, unclean or broken APIs affect everyone, not only the few maintaining only one part of PHP, and only on one single platform. It will also affects end users projects, the health of a project affects everyone using it. because I am rushing, I have be rushing for months to make the work done.. Most part of this work has been done in secret, without discussing with anyone but between you guys. While we were talking about our plans for php-next, even began the work, you were rushing to get phpng ready for the announce or release. You did not participate to any discussions nor proposed anything, not even mentioning your work on phpng. This is not the PHP I want to work with, it never was. Also rushing does not mean the work get done correctly. It is often the contrary. We can see that with phpng, you guys have worked very hard, but you worked in a bubble and now you come out of this bubble and tell us that it is all you want for next and that we should do it within a year. No, sorry, I can't and won't accept that. last of all : all above is my personal comments, has nothing to do with Zend... It has a lot to do with Zend given that Zend funds you to work on phpng and disallows you to communicate about it until it is announced (NDA). It is a shame to have NDAs to work on the core. It is a shame to come now and say things like why should we
Re: [PHP-DEV] RFC: Move phpng to master
Hi David, On Tue, Jul 22, 2014 at 2:42 PM, David Soria Parra dso...@gmx.net wrote: Even if we have PHP-5.7 branch, we have merge up policy. Therefore, any new feature will end up with master, I suppose. If a new feature is only available to PHP-5.7 branch, it's a merge bug, isn't it? Regards, We had this policy before and it didn't help us. The problem is maintiaining all the branches and keeping people interested in the next branch because people tend to focus on the currently release branch. When we decided upon the release RFC we talked a lot about the overhead of maintaing multiple branches and tried to reduce the amount of branches. In particular with API changes it becomes tidious if we try to maintain a feature across branches and that implicit divergence has to be resolved better sooner or later, or otherwise it would be just like the old php6 again. I can understand your concern. We have git now and git can easily spot what and who haven't merged required changes to master. Working with multiple branches and merge is much easier with git also. I think this time it will work, hopefully. My concern is development time. It's too short. We only have about half of a year to feature freeze. More than a year would be appropriate for a major version up, IMHO. Long alpha/beta period is good for users also. Having PHP-5.7 is not a mandatory, but I would like to have it. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: Move phpng to master
On 22/07/14 03:58, Pierre Joye wrote: Now, as I already suggested many times (but with zero reply from Zend's), let step back, get our roadmap setup, todos, goals, agreement and get back to work. But a forcing move to php-next within a year with almost only phpng is a major mistake and will most likely create a major problem within the php community, especially for php.net. We are not in a positiion to do such mistake,. It is time to get our stuff together, to work as a team, this is out last chance, and phpng is not worth it in comparison. Perhaps it may surprise some people, but I totally agree with Pierre here. Given that the majority of MY time is spent these days trying to play catchup, I am only really interested in fixing the remaining holes in the user end of PHP. Rebuilding the guts really has little interest ... I've been through the same exercise with Firebird and we still use the older versions because it does the job! Much of the esoteric additions to PHP have absolutely no interest to me and in many cases it's these which are creating the problems phpng is now trying to fix? When I started at this lark 10+ years ago I could write PHP5 code that gracefully rolled back to PHP4 and just worked. These days I'm not even sure exactly what I'm even trying to fix ... I just work through a list of warnings ... that is AFTER I get rid of the white screens! NOT having control over much of the shared hosting environment I'm having to work with, the current spread of incompatible configurations is a major roadblock, and what is stopping even PHP5.2 from being phased out :( Perhaps it IS time to reinstate PHP6! We know what the mistakes were and have a better understanding of how things should have been done. With the rest of the world already using Unicode and 64bit hardware, it's these areas that need putting to bed in the core which is much more important than a major code rework. Then phpng can be PHP7. Trying to continue to shoehorn improvements into PHP5.x without the flexibility to break the bits that DO need breaking is what is holding up progress, and if phpng has been developed properly then it can be merged in again later ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On 22/07/14 07:44, Dmitry Stogov wrote: Big PHP users just can't not to care about performance, because it's money. I know most of them already experimented with HHVM. Big users don't use PHP ... If we don't provide adequate replay, we may turn back into the language for home pages. Is that such a bad thing? Perhaps it is time there was a PHPHome and PHPCommercial ? Perhaps that is the problem these days :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Tue, Jul 22, 2014 at 11:11 AM, Lester Caine les...@lsces.co.uk wrote: On 22/07/14 07:44, Dmitry Stogov wrote: Big PHP users just can't not to care about performance, because it's money. I know most of them already experimented with HHVM. Big users don't use PHP ... You are wrong :) Thanks. Dmitry. If we don't provide adequate replay, we may turn back into the language for home pages. Is that such a bad thing? Perhaps it is time there was a PHPHome and PHPCommercial ? Perhaps that is the problem these days :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Move phpng to master
-Original Message- From: Lester Caine [mailto:les...@lsces.co.uk] Sent: Tuesday, July 22, 2014 10:12 AM To: PHP internals Subject: Re: [PHP-DEV] RFC: Move phpng to master Big users don't use PHP ... Just to elaborate (slightly) on Dmitry's answer - this is an absolutely wrong and also fairly dangerous misconception. PHP is the most widely used dynamic language out there for web sites, and it's used by many of the largest companies out there. In fact, there are very few companies that don't use PHP at all - whether it's for their main website or internal apps. Judging by the response to my benchmarks post (10K views in the first 5 days, which I have to admit is very uncommon), the number of retweets, questions and discussions it sparked - I'd say the level of interest is very, very high. I do recommend that instead of wasting time arguing about theory, at least at this point, we focus on doing. The first logical step (in my humble opinion) is to move phpng into master and close any remaining gaps as quickly as possible. In parallel, people who want to get additional things into 6/7 should hustle, instead of assuming they have 2-3 years of lingering to rely on. RFCs we already agreed are going to be in the next version - like the uniform variable syntax and the 64-bit patch - will make it into master pretty quickly, I think we can count on Nikita here. For 6/7, we should primarily focus on things that we can only do in a major version - i.e. things that break compatibility. We should do so while keeping in mind that this is *not* an opportunity for wholesale breakage, as then we risk very slow or no migration (like we had between 4 and 5). New features can be added in the yearly .1/.2 releases too - so if they make it into .0 - great, but if not, no big deal. I stand by my statement that I'm sure a great deal of users (my guesstimate - the majority) would happily upgrade to PHP.NEXT even if the huge performance gains were the only thing there. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
hi, On Tue, Jul 22, 2014 at 9:52 AM, Zeev Suraski z...@zend.com wrote: I stand by my statement that I'm sure a great deal of users (my guesstimate - the majority) would happily upgrade to PHP.NEXT even if the huge performance gains were the only thing there. I fully agree with you about breakages. It should be carefully for painful areas (like what is done in the variable syntax RFC) but big breaks should be avoided. However I disagree with your statement about what users expect for next. It is obvious that users are happy to see PHP performing better, there is no need to do a study to realize that. On the other hand, performance is not their higher priorities for the next major version. I spoke to many big php users, UG, etc in the last months and the expectations go way beyond performance. Internals code cleanup is very very important point (more and more custom extensions are being internally developed, be OSS or not), our APIs and implemenation are a mess, we all know that. A cleanup is long due, since the php 4 to 5 move. Back then you, along other, rejected many of these cleanup arguing that it could be done later. Without blaming any of us, we see now that we never do such things later. The other important parts are things like type hinting for scalar, to match the class type hinting, getter/setter (100% positive feedback to do what we proposed in the related RFC), object like methods for array/string, keeping BC with the existing APIs but providing cleaner userfriendlier APIs, etc. It is basically what we can find in the ideas page about php6, a page I created months ago and began to discuss. These discussions happened here, publically, and you (phpng's) never replied to any of them. This is what we should discuss now, not tomorrow, not when phpng is merged (if it ever happens). This is what allows us to do an informed guess for a possible release cycle for php-next. I will post a proposal for a timetable, something that could fit for both sides. Do not expect it to match your one year requirement, but it won't be three years either. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Tue, Jul 22, 2014 at 10:45 AM, Pierre Joye pierre@gmail.com wrote: hi, On Tue, Jul 22, 2014 at 9:52 AM, Zeev Suraski z...@zend.com wrote: I stand by my statement that I'm sure a great deal of users (my guesstimate - the majority) would happily upgrade to PHP.NEXT even if the huge performance gains were the only thing there. Internals code cleanup is very very important point (more and more custom extensions are being internally developed, be OSS or not), our APIs and implemenation are a mess, we all know that. A cleanup is long due, since the php 4 to 5 move. This is the opportunity to do the cleanup now, based on phpng branch. Since the branch is pulic on Github, how is development secret? With Zend, Nikita and laurence putting so much time into this, I fail to see how it would work to notify everyone of all the changes they are doing. As with every big project you have to put time into following its progress. I agree though that Zend (Zeev, Dimitry) could improve the RFC with a little more details, its focussing a lot on performance. As i understood Nikita and laurence they are already improving it based on the first prototype from month ago. Honestly, if Nikita says converting his extensions improved the API a lot then this is a good sign for me already. The other important parts are things like type hinting for scalar, to match the class type hinting, getter/setter (100% positive feedback to do what we proposed in the related RFC), object like methods for array/string, keeping BC with the existing APIs but providing cleaner userfriendlier APIs, etc. It is basically what we can find in the ideas page about php6, a page I created months ago and began to discuss. These discussions happened here, publically, and you (phpng's) never replied to any of them. This is what we should discuss now, not tomorrow, not when phpng is merged (if it ever happens). This is what allows us to do an informed guess for a possible release cycle for php-next. I will post a proposal for a timetable, something that could fit for both sides. Do not expect it to match your one year requirement, but it won't be three years either. I think internal refactoring is exactly the reason to move from 5 to 6/7 and not necessarily end user facing changes. i wouldn't mind starting type hinting, getter/setter or any other discussion again once a 6.0/7.0 is out. This has worked for PHP since 5.3, 5.4, 5.5. I'd rather just take the performance gains, given that PHP as a language just works(tm), additional features are nice, but not having them is not a show stopper and shouldn't block something as big as phpng. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Tue, Jul 22, 2014 at 11:18 AM, Benjamin Eberlei kont...@beberlei.de wrote: This is the opportunity to do the cleanup now, based on phpng branch. Since the branch is pulic on Github, how is development secret? Benjamin, please check the background before replying. 80% of phpng development has been done secretly, before it was even announced. This development happened while we were discussing, collaborating, working on what will be php-next, including the long due 64bit patch. These actions and discussion have done without any feedback from any of the phpng developers. I can't blame them for not talking about phpng, but to have signed a NDA to do work on PHP itself. With Zend, Nikita and laurence putting so much time into this, I fail to see how it would work to notify everyone of all the changes they are doing. As with every big project you have to put time into following its progress. I agree though that Zend (Zeev, Dimitry) could improve the RFC with a little more details, its focussing a lot on performance. A little? There is no details, there is no doc, there is nothing but a huge set of patches. As i understood Nikita and laurence they are already improving it based on the first prototype from month ago. Honestly, if Nikita says converting his extensions improved the API a lot then this is a good sign for me already. It does not improve anything from an extension developer point of view, or very little. On the other APIs are more dangerous, confusing and inconsistent. The other important parts are things like type hinting for scalar, to match the class type hinting, getter/setter (100% positive feedback to do what we proposed in the related RFC), object like methods for array/string, keeping BC with the existing APIs but providing cleaner userfriendlier APIs, etc. It is basically what we can find in the ideas page about php6, a page I created months ago and began to discuss. These discussions happened here, publically, and you (phpng's) never replied to any of them. This is what we should discuss now, not tomorrow, not when phpng is merged (if it ever happens). This is what allows us to do an informed guess for a possible release cycle for php-next. I will post a proposal for a timetable, something that could fit for both sides. Do not expect it to match your one year requirement, but it won't be three years either. I think internal refactoring is exactly the reason to move from 5 to 6/7 and not necessarily end user facing changes. i wouldn't mind starting type hinting, getter/setter or any other discussion again once a 6.0/7.0 is out. This has worked for PHP since 5.3, 5.4, 5.5. Again once it is out? In which world do you live? that will never happen. We have an opportunity now to do it, let do it. Also I am very surprised to read that from you, I thought you were a strong supporter of these features, or annotations. I'd rather just take the performance gains, given that PHP as a language just works(tm), additional features are nice, but not having them is not a show stopper and shouldn't block something as big as phpng. It is. And performance is by no mean the main PHP problem, despite HHVM. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On 22/07/14 10:32, Pierre Joye wrote: As i understood Nikita and laurence they are already improving it based on the first prototype from month ago. Honestly, if Nikita says converting his extensions improved the API a lot then this is a good sign for me already. It does not improve anything from an extension developer point of view, or very little. On the other APIs are more dangerous, confusing and inconsistent. And unavailability of extensions is a blocker currently as well. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Tue, Jul 22, 2014 at 3:42 AM, Xinchen Hui larue...@gmail.com wrote: Hey: I really don't like arguing in english, so this will be my last reply in this thread. sorry to bother you, and my backlash wasn't really targeted you personally. On Tue, Jul 22, 2014 at 12:10 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Mon, Jul 21, 2014 at 5:28 PM, Xinchen Hui larue...@gmail.com wrote: Hey: 在 2014年7月21日，19:02，Ferenc Kovacs tyr...@gmail.com 写道： On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski z...@zend.com wrote: He just asks if we will have a 5.7 release while working on the next major in master. I don't think that we can release the php-next under a years, so I think that an 5.7 could be warranted (to keep up with our roadmap), but depends on wether or not we have enough new (BC-safe) features. I don’t see a reason of why we can’t have this major version ready by or even sooner than the current yearly rhythm we have. In fact, if we do aim to work in parallel on both 5.7 and .NEXT � we’re likely to needlessly delay .NEXT… Zeev because there is so much stuff which we want to do in the next major version, but we can't even start because there is no stable base to target the other php-next features. What they are? Please come with RFC and Patches. https://wiki.php.net/rfc/uniform_variable_syntax https://wiki.php.net/rfc/size_t_and_int64_next aren't they discussed and voted? what do you mean by we can't even start in previous comment? yes, and both of those were put on hold by the authors until the phpng situation is resolved, and to me it feels wrong to block something which is done and accepted with something which is not-yet finished(albeit it seems to be reaching a stable state) and didn't have a consensus behind it. Or you suggest we stop the current work to waiting them come their self? I'm saying that we should resolve the current situation where people can't work on stuff which would target php-next, because it is still a moving target. why Nikita could work on it? why me can work on it? I'm not saying that you should implement other people's RFCs. we have a couple of options: - ignore phpng with the other RFCs/changes, and continue working on master, making it your problem to try to stabilize phpng while catching up to a constantly moving target, which is bad. - we could also continue the current trend that we simply don't merge stuff until phpng is voted and merged, which is bad - we could also work together to sort out the controversial topics/features about the current phpng branch, and figure out a way to either resolve the issues, or exclude those stuff from the initial merge, and have most of the phpng stuff merged into master, so we can start working together in a common branch instead of blocking each other. I'm saying that it is nice that you(the phpng main devs) are confident that you can stabilize your changes so making a php-next release in less than a year, but other people have other ideas which can only happen in a major version, and you shouldn't rush an early release which would mean that the next window of opportunity for major refactor is in the next decade. I am not sure about you attitude here, from these words, seems you agree to merge phpng to master asap, then people can start work on it? yes! I'm saying that it is pretty unfortunate that we have to decide to between reviewing/accepting a huuuge chunk of changes or rejecting a significant performance boost and some api cleanup. we shouldn't, at least most people here shouldn't, only the guys who need to maintain them should. what I wanted to say that it is better to review and merge smaller chunks of changes. I know that You Can't Cross a Chasm in Two Small Steps, eg. that the initial work has to be done, but I think what we have is already more than enough for the initial merge. I'm saying that we should stop pushing our own agendas, and figure out the best possible solution for the current situation, so that we can go forward with the development with the normal workflow, where everybody is on the same page, controversial changes are done through RFCs and we don't block each other from the work. you know what? I really don't like we should; we must, they means nothing.. I have spent lots of my time to work on PHP/PHPNG, more than 80 hours per month. I treat it like a regular work, dmitry spends more than me(8 hours per day). you ask me to stop to wait somebody who even can not work hours a month here? with all my respects: I really upset by people who always told you, hey man, don't be rush... because I am rushing, I have be rushing for months to make the work done.. last of all : all above is my personal comments, has nothing to do with Zend... I'm
Re: [PHP-DEV] RFC: Move phpng to master
On Tue, Jul 22, 2014 at 11:32 AM, Pierre Joye pierre@gmail.com wrote: On Tue, Jul 22, 2014 at 11:18 AM, Benjamin Eberlei kont...@beberlei.de wrote: This is the opportunity to do the cleanup now, based on phpng branch. Since the branch is pulic on Github, how is development secret? Benjamin, please check the background before replying. 80% of phpng development has been done secretly, before it was even announced. This development happened while we were discussing, collaborating, working on what will be php-next, including the long due 64bit patch. These actions and discussion have done without any feedback from any of the phpng developers. I can't blame them for not talking about phpng, but to have signed a NDA to do work on PHP itself. I know the background and the int64 clash was unfortunate, however it was resolved from what I see in a good compromise. I don't see how starting to work on some feature/refactoring requires immediate communication with all of the team, since you need to prove it works first, obviously you have the prototype then, which is always kind of secret, because you are the only one who worked on it. Everybody can put their own time where they want in Open-Source, and since After the initial prototype there was the announcment, no ninja merge or similar, discussion is still possible. But this requires constructive review of the patches and pull requests, like its done in any project I worked on (Symfony, Doctrine, ..). Instead this discussion has already gone south again discussing about politics instead of the actual code. With Zend, Nikita and laurence putting so much time into this, I fail to see how it would work to notify everyone of all the changes they are doing. As with every big project you have to put time into following its progress. I agree though that Zend (Zeev, Dimitry) could improve the RFC with a little more details, its focussing a lot on performance. A little? There is no details, there is no doc, there is nothing but a huge set of patches. As i understood Nikita and laurence they are already improving it based on the first prototype from month ago. Honestly, if Nikita says converting his extensions improved the API a lot then this is a good sign for me already. It does not improve anything from an extension developer point of view, or very little. On the other APIs are more dangerous, confusing and inconsistent. So there is your opinion aginst Nikita's. He has already ported his extensions and gave a positive opinion. The other important parts are things like type hinting for scalar, to match the class type hinting, getter/setter (100% positive feedback to do what we proposed in the related RFC), object like methods for array/string, keeping BC with the existing APIs but providing cleaner userfriendlier APIs, etc. It is basically what we can find in the ideas page about php6, a page I created months ago and began to discuss. These discussions happened here, publically, and you (phpng's) never replied to any of them. This is what we should discuss now, not tomorrow, not when phpng is merged (if it ever happens). This is what allows us to do an informed guess for a possible release cycle for php-next. I will post a proposal for a timetable, something that could fit for both sides. Do not expect it to match your one year requirement, but it won't be three years either. I think internal refactoring is exactly the reason to move from 5 to 6/7 and not necessarily end user facing changes. i wouldn't mind starting type hinting, getter/setter or any other discussion again once a 6.0/7.0 is out. This has worked for PHP since 5.3, 5.4, 5.5. Again once it is out? In which world do you live? that will never happen. We have an opportunity now to do it, let do it. Also I am very surprised to read that from you, I thought you were a strong supporter of these features, or annotations. PHP 5.3, 5.4 and 5.5 had fantastic feature additions and they are only minor releases. I am a strong supporter of those features, however they have been voted out several times, so I have accepted that they will probably be never in the Core. I don't mind, they are just syntactic glue, PHP works for me anyways. What I would hate to see is that PHP 6/7 blocks itself by wanting to be too much, failing again or delaying years like PHP 5.3. I agree with Zeev that if phpng is going to be master, then this should be released sometime next year. Btw, it is your credit that we have the RFC process now, so i fail to see how this would mean we have another 10 years of PHP 6/7 deadlock, the release schedule increased massively since then and I expect this to continue, even more so with the HHVM competition. I'd rather just take the performance gains, given that PHP as a language just works(tm), additional features are nice, but not having them is not a show stopper and shouldn't block
Re: [PHP-DEV] RFC: Move phpng to master
On Tue, Jul 22, 2014 at 11:58 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Jul 22, 2014 at 3:42 AM, Xinchen Hui larue...@gmail.com wrote: Hey: I really don't like arguing in english, so this will be my last reply in this thread. sorry to bother you, and my backlash wasn't really targeted you personally. On Tue, Jul 22, 2014 at 12:10 AM, Ferenc Kovacs tyr...@gmail.com wrote: https://wiki.php.net/rfc/uniform_variable_syntax https://wiki.php.net/rfc/size_t_and_int64_next aren't they discussed and voted? what do you mean by we can't even start in previous comment? yes, and both of those were put on hold by the authors until the phpng situation is resolved, and to me it feels wrong to block something which is done and accepted with something which is not-yet finished(albeit it seems to be reaching a stable state) and didn't have a consensus behind it. To make sure that this isn't misconstrued as an argument against merging phpng: My work isn't blocked by phpng (it's actually based on it), it's blocked by lack of an official decision regarding phpng. I have another large patch (AST) based on phpng and Andrea is working on a bigint implementation, also based on phpng. Before these things can move forward we need the decision that PHP 6/7 is going to be based on phpng. Nikita
Re: [PHP-DEV] RFC: Move phpng to master
On Tue, Jul 22, 2014 at 12:11 PM, Benjamin Eberlei kont...@beberlei.de wrote: On Tue, Jul 22, 2014 at 11:32 AM, Pierre Joye pierre@gmail.com wrote: On Tue, Jul 22, 2014 at 11:18 AM, Benjamin Eberlei kont...@beberlei.de wrote: This is the opportunity to do the cleanup now, based on phpng branch. Since the branch is pulic on Github, how is development secret? Benjamin, please check the background before replying. 80% of phpng development has been done secretly, before it was even announced. This development happened while we were discussing, collaborating, working on what will be php-next, including the long due 64bit patch. These actions and discussion have done without any feedback from any of the phpng developers. I can't blame them for not talking about phpng, but to have signed a NDA to do work on PHP itself. I know the background and the int64 clash was unfortunate, however it was resolved from what I see in a good compromise. There was no compromise but forcing a move on something that does not exist yet. We made the step to propose a merge with phpng if phpng is ever accepted. No step done from the phpng team, in contrary. So much about coop and trust of said promises. I don't see how starting to work on some feature/refactoring requires immediate communication with all of the team, since you need to prove it works first, obviously you have the prototype then, which is always kind of secret, because you are the only one who worked on it. There is a huge difference between working on a specific feature and do a total rewamp of the core, breaking APIs even more, for months, ignoring discussions about the exact same topic, let other waste *months* of work by doing so. Even have the mood to say that there is no plan to replace master with phpng and then come up with such proposal. I am sorry, but I totally fail to understand that we could even consider this behavior as good or normal. Everybody can put their own time where they want in Open-Source, and since After the initial prototype there was the announcment, no ninja merge or similar, discussion is still possible. But this requires constructive review of the patches and pull requests, like its done in any project I worked on (Symfony, Doctrine, ..). Instead this discussion has already gone south again discussing about politics instead of the actual code. What you see as politics, I see it as the core issues in why the PHP project does not work as team. With Zend, Nikita and laurence putting so much time into this, I fail to see how it would work to notify everyone of all the changes they are doing. As with every big project you have to put time into following its progress. I agree though that Zend (Zeev, Dimitry) could improve the RFC with a little more details, its focussing a lot on performance. A little? There is no details, there is no doc, there is nothing but a huge set of patches. As i understood Nikita and laurence they are already improving it based on the first prototype from month ago. Honestly, if Nikita says converting his extensions improved the API a lot then this is a good sign for me already. It does not improve anything from an extension developer point of view, or very little. On the other APIs are more dangerous, confusing and inconsistent. So there is your opinion aginst Nikita's. He has already ported his extensions and gave a positive opinion. Well, seriously, are you surprised that one of the phpng developer likes what phpng changes? I am not. And phpng solves none of the current APIs issue and code awful state. I am not alone to say it and I am not alone to see it. PHP 5.3, 5.4 and 5.5 had fantastic feature additions and they are only minor releases. I am a strong supporter of those features, however they have been voted out several times, so I have accepted that they will probably be never in the Core. I don't mind, they are just syntactic glue, PHP works for me anyways. What I would hate to see is that PHP 6/7 blocks itself by wanting to be too much, failing again or delaying years like PHP 5.3. I agree with Zeev that if phpng is going to be master, then this should be released sometime next year. No way. It is impossible and there is so much chances to fuck it up by rushing it this way. And as usual, we will have to take of this mess for the next decade. This is not something I can live with. Btw, it is your credit that we have the RFC process now, so i fail to see how this would mean we have another 10 years of PHP 6/7 deadlock, the release schedule increased massively since then and I expect this to continue, even more so with the HHVM competition. That being said, between one year and six years there is a medium way. And this is the way I strongly recommend. What you do not seem to see or understand is that engine/core refactoring can't and won't happen post 6/7.0.0, for obvious reasons like API BC or similar
Re: [PHP-DEV] RFC: Move phpng to master
On Tue, Jul 22, 2014 at 12:15 PM, Nikita Popov nikita@gmail.com wrote: On Tue, Jul 22, 2014 at 11:58 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Jul 22, 2014 at 3:42 AM, Xinchen Hui larue...@gmail.com wrote: Hey: I really don't like arguing in english, so this will be my last reply in this thread. sorry to bother you, and my backlash wasn't really targeted you personally. On Tue, Jul 22, 2014 at 12:10 AM, Ferenc Kovacs tyr...@gmail.com wrote: https://wiki.php.net/rfc/uniform_variable_syntax https://wiki.php.net/rfc/size_t_and_int64_next aren't they discussed and voted? what do you mean by we can't even start in previous comment? yes, and both of those were put on hold by the authors until the phpng situation is resolved, and to me it feels wrong to block something which is done and accepted with something which is not-yet finished(albeit it seems to be reaching a stable state) and didn't have a consensus behind it. To make sure that this isn't misconstrued as an argument against merging phpng: My work isn't blocked by phpng (it's actually based on it), it's blocked by lack of an official decision regarding phpng. I have another large patch (AST) based on phpng and Andrea is working on a bigint implementation, also based on phpng. Before these things can move forward we need the decision that PHP 6/7 is going to be based on phpng. sorry if I wasn't clear enough, this is exactly what I meant by but we can't even start because *there is no stable base to target the other php-next* features.. I should have quoted your mail where you mention that you will put on hold until the master-phpng situation is resolved. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski z...@zend.com wrote: He just asks if we will have a 5.7 release while working on the next major in master. I don't think that we can release the php-next under a years, so I think that an 5.7 could be warranted (to keep up with our roadmap), but depends on wether or not we have enough new (BC-safe) features. I don’t see a reason of why we can’t have this major version ready by or even sooner than the current yearly rhythm we have. In fact, if we do aim to work in parallel on both 5.7 and .NEXT – we’re likely to needlessly delay .NEXT… Zeev Hi Zeev, The discussion seems to be sidetracked by the topic on when should we release PHP-NEXT and what else should it contains. Could we agree to put that aside for now, and agree to discuss this later, after we managed to have a consensus on merging phpng to master? I think that it is an important question, but not having phpng in master block the other features/changes as well, and we don't have to decide about the roadmap/features for PHP-NEXT right now. Thanks for your understanding! -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] RFC: Move phpng to master
On 22/07/14 13:17, Ferenc Kovacs wrote: The discussion seems to be sidetracked by the topic on when should we release PHP-NEXT and what else should it contains. Could we agree to put that aside for now, and agree to discuss this later, after we managed to have a consensus on merging phpng to master? I think that it is an important question, but not having phpng in master block the other features/changes as well, and we don't have to decide about the roadmap/features for PHP-NEXT right now. PHPNext is a side issue as it does not need phpng ... What seems to be missing here is any real possibility of a review of all the aspects of phpng and IF each of those make sense - in light of developments others have been working on. It does sound very much as if phpng is already a done deal and it just need to be rubber stamped into the main development stream? There has been complaints about not being able to review decisions made behind closed doors but my own concern as always is the effect on extensions I use. These sorts of substantial reworks broke interbase for many versions back in the 5.0/5.1 days and it was not until 5.1.6 that a working version was restored! Interbase is not even included in phpng yet ... as are other database interfaces ... areas where performance can be tuned by offloading work rather than downloading data unnecessarily. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Tue, Jul 22, 2014 at 2:17 PM, Ferenc Kovacs tyr...@gmail.com wrote: Hi Zeev, The discussion seems to be sidetracked by the topic on when should we release PHP-NEXT and what else should it contains. Could we agree to put that aside for now, and agree to discuss this later, after we managed to have a consensus on merging phpng to master? I do not think it is reasonable to do so. Empty promises are never met. Once it is in, we will be doomed, blocking additions or change in the name of a 1% perf etc will be common, let alone migration guides, documentations, etc. I think that it is an important question, but not having phpng in master block the other features/changes as well, and we don't have to decide about the roadmap/features for PHP-NEXT right now. Thanks for your understanding! None of the worries have been solved, so we are going to vote on given phpng white card and hope everything will be fine. History told me that it does not work. On the hand, some clear statements about the numerous questions raised here, updated docs and migrations guide, list of actual changes and how, all these things will help to take an informed decisions instead of shooting in the dark and hoping for the best. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On 22 ביול 2014, at 15:17, Ferenc Kovacs tyr...@gmail.com wrote: Hi Zeev, The discussion seems to be sidetracked by the topic on when should we release PHP-NEXT and what else should it contains. Could we agree to put that aside for now, and agree to discuss this later, after we managed to have a consensus on merging phpng to master? I think that it is an important question, but not having phpng in master block the other features/changes as well, and we don't have to decide about the roadmap/features for PHP-NEXT right now. Thanks for your understanding! I wholeheartedly agree with you, we absolutely can postpone it - the RFC doesn't deal with that actually. Once the RFC is approved (I hope), I think we'd then need to discuss fairly quickly what we aim for - a release sometime next year or later. Until that happens, I think we should make no assumptions on 5.7 (which is what started the timeline discussion) - one way or the other. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski z...@zend.com wrote: Once the RFC is approved (I hope) Before the merge RFC can be considered for voting, I think it is critical that you provide a comprehensive migration guide highlighting the changes required from core developers. This means https://wiki.php.net/phpng-upgrading should be completed to reflect all changes. It is only then that we can vote with knowledge of how much this big patch affects the codebase. Best, -- Etienne Kneuss
Re: [PHP-DEV] RFC: Move phpng to master
On Tue, 22 Jul 2014, Etienne Kneuss wrote: On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski z...@zend.com wrote: Once the RFC is approved (I hope) Before the merge RFC can be considered for voting, I think it is critical that you provide a comprehensive migration guide highlighting the changes required from core developers. This means https://wiki.php.net/phpng-upgrading should be completed to reflect all changes. It is only then that we can vote with knowledge of how much this big patch affects the codebase. *this* is something I very much would like to see too. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
I'll try to do this. It would be great, if someone may help. Thanks. Dmitry. On Tue, Jul 22, 2014 at 5:18 PM, Etienne Kneuss etienne.kne...@epfl.ch wrote: On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski z...@zend.com wrote: Once the RFC is approved (I hope) Before the merge RFC can be considered for voting, I think it is critical that you provide a comprehensive migration guide highlighting the changes required from core developers. This means https://wiki.php.net/phpng-upgrading should be completed to reflect all changes. It is only then that we can vote with knowledge of how much this big patch affects the codebase. Best, -- Etienne Kneuss
Re: [PHP-DEV] RFC: Move phpng to master
On 22/07/14 14:37, Derick Rethans wrote: Before the merge RFC can be considered for voting, I think it is critical that you provide a comprehensive migration guide highlighting the changes required from core developers. This means https://wiki.php.net/phpng-upgrading should be completed to reflect all changes. It is only then that we can vote with knowledge of how much this big patch affects the codebase. *this* is something I very much would like to see too. Zend has a new zend_string API would seem to merit a little more than a single line? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On 22/07/2014 15:37, Derick Rethans wrote: On Tue, 22 Jul 2014, Etienne Kneuss wrote: On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski z...@zend.com wrote: Once the RFC is approved (I hope) Before the merge RFC can be considered for voting, I think it is critical that you provide a comprehensive migration guide highlighting the changes required from core developers. This means https://wiki.php.net/phpng-upgrading should be completed to reflect all changes. It is only then that we can vote with knowledge of how much this big patch affects the codebase. *this* is something I very much would like to see too. I agree. It might sound silly, but it would also be interesting to know what could be the effect of phpng on the potential ideas for php6/7 from https://wiki.php.net/ideas/php6 (if any). For most of them it's pretty clear that there's isn't an overlap, but how about unicode support? Its implementation might undo or reduce some of the performance gains obtained in phpng. Or, if you put it the other way around: if we merge phpng to master it might not be acceptable to think about adding utf8 support. Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Tue, Jul 22, 2014 at 4:10 PM, Matteo Beccati p...@beccati.com wrote: On 22/07/2014 15:37, Derick Rethans wrote: On Tue, 22 Jul 2014, Etienne Kneuss wrote: On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski z...@zend.com wrote: Once the RFC is approved (I hope) Before the merge RFC can be considered for voting, I think it is critical that you provide a comprehensive migration guide highlighting the changes required from core developers. This means https://wiki.php.net/phpng-upgrading should be completed to reflect all changes. It is only then that we can vote with knowledge of how much this big patch affects the codebase. *this* is something I very much would like to see too. I agree. It might sound silly, but it would also be interesting to know what could be the effect of phpng on the potential ideas for php6/7 from https://wiki.php.net/ideas/php6 (if any). For most of them it's pretty clear that there's isn't an overlap, but how about unicode support? Its implementation might undo or reduce some of the performance gains obtained in phpng. Or, if you put it the other way around: if we merge phpng to master it might not be acceptable to think about adding utf8 support. One can make wishlists, but I don't think we have any people who is familiar with the area and willing to work for this to happen(unfortunately). Of course such a person/group of people can step up and would be welcome to do so, but I see no point of trying to feature box a release without having anybody actually working towards those goals. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] RFC: Move phpng to master
Hi, On Tue, Jul 22, 2014 at 3:18 PM, Etienne Kneuss etienne.kne...@epfl.ch wrote: This means https://wiki.php.net/phpng-upgrading should be completed to reflect all changes. as a pure consumer maintaining some internal extensions, I would very much like to see this too, at least when you decide to go ahead with the merge. Btw: I have, of course, no say on this as a pure consumer, but there was the discussion of whether the performance improvement alone without any other features would already make consumers excited. To which I can say: Heck yeah. Me personally, I would be very happy to see the speed improvement and I have zero issues in adopting our internal extensions to the new API, especially when it's for a new major release. Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
Hi! As we’re getting closer to release 5.6.0, and given the very high level of interest in phpng, I think it’s time for us to provide some clarity regarding what happens post 5.6.0. Dmitry and I wrote an RFC proposing that we merge phpng into master and turn it into the basis of the next major version of PHP (name TBD). I think before we do that we need to do much better documentation around the changes in the engine. I know that in the past we followed the code is documentation pattern, but the code there becomes more and more dense, with macros upon macros upon macros, and myriads of micro-optimizations which make sense only in specific context. Absent that context and documentation, understanding what is going on becomes much harder and so becomes dealing with that code. Some of the changes right now are partially documented in https://wiki.php.net/phpng-int, some (like parameter parsing API) not documented at all. Given that, I'm not even sure I understand what phpng is right now - as I didn't have time to parse every commit during active development. So it would be nice to have some internal docs if we want people to form an informed opinion about what is being proposed. And, of course, the porting guide for extension authors is another required part. I know the phpng team did great work porting the extensions, but people would need to support them and add the new ones, so it is a must. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
hi Zeev, On Mon, Jul 21, 2014 at 9:31 AM, Zeev Suraski z...@zend.com wrote: All, As we’re getting closer to release 5.6.0, and given the very high level of interest in phpng, I think it’s time for us to provide some clarity regarding what happens post 5.6.0. Dmitry and I wrote an RFC proposing that we merge phpng into master and turn it into the basis of the next major version of PHP (name TBD). The RFC is available at https://wiki.php.net/rfc/phpng Some supporting links available down below. Comments welcome! Quoting Dmitry's mail from last week phpng is an experimental branch, as such, I see no appealing reasons to replace master with phpng and use phpng as base for the next major version. I am not really surprised by this request, despite contradictory comments about this exact point in the past few weeks. Despite the excellent performance improvements, it is by far not ready to be used as base for the next major release, the release we will have to maintain for the next decade. There is almost no documentation, the APIs are not clean or inconsistent (just came back home, will provide details later) but having two separate zpp, same area's functions mixing use of zend_char and char (creating hard to catch bugs, not always catch-able at compile time f.e.), no (known) plan about when the experiments will stop and when or how deep the cleanup will be done. In other words, I cannot agree to replace master with phpng, not with its current state and it is definitively not what I could imagine as a base for php-next. A roadmap, undocumented and plan-less development (sorry, but stacking up a couple of % performance improvement has little to nothing to do with designing php-next) is the best way to fail to have what many of our users and developers could expect for php-next. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 9:52 AM, Pierre Joye pierre@gmail.com wrote: hi Zeev, On Mon, Jul 21, 2014 at 9:31 AM, Zeev Suraski z...@zend.com wrote: All, As we’re getting closer to release 5.6.0, and given the very high level of interest in phpng, I think it’s time for us to provide some clarity regarding what happens post 5.6.0. Dmitry and I wrote an RFC proposing that we merge phpng into master and turn it into the basis of the next major version of PHP (name TBD). The RFC is available at https://wiki.php.net/rfc/phpng Some supporting links available down below. Comments welcome! Quoting Dmitry's mail from last week phpng is an experimental branch, as such, I see no appealing reasons to replace master with phpng and use phpng as base for the next major version. I am not really surprised by this request, despite contradictory comments about this exact point in the past few weeks. Despite the excellent performance improvements, it is by far not ready to be used as base for the next major release, the release we will have to maintain for the next decade. There is almost no documentation, the APIs are not clean or inconsistent (just came back home, will provide details later) but having two separate zpp, same area's functions mixing use of zend_char and char (creating hard to catch bugs, not always catch-able at compile time f.e.), no (known) plan about when the experiments will stop and when or how deep the cleanup will be done. In other words, I cannot agree to replace master with phpng, not with its current state and it is definitively not what I could imagine as a base for php-next. A roadmap, undocumented and plan-less development (sorry, but stacking up a couple of % performance improvement has little to nothing to do with designing php-next) is the best way to fail to have what many of our users and developers could expect for php-next. Cheers, -- Pierre Hi I can only agree here. I'd like a clean API. We need to consider PHP-Next jump as an opportunity to clean our API and finally have something understandable for a newcomer, and documented. That's a move nobody dared to take in the last decade, degrading more and more our codebase in term of understandability and flexibility. This can't last Old features and unused things should be cleaned up. Quickly caught, impacting the engine : - Resources are a hell, mixed with zend_lists etc... inconsitstent and absolutely PITA to develop with. - Streams need to be cleaned up and reworked to support full asynchronous IOs, which could involve threads, thus engine tied - Signals have been worked on starting with 5.4 (AFAIR), but never activated by default. I guess the actual implementation lacks a bit more reflection to be stable, and to finally propose signal managers into userland. ext/pcntl should be somehow merged to core, and this as well would involve engine work - TSRM need to find love, or to find a better replacement, which would involve a big engine work as well - ... and so on Macro hell should be reworked as inlined functions, and I'd like we start supporting C99 as well. Performance is a userland point. API, doc, and clean things are developers points, and IMO, they are as important. What about merging OPCache to the branch ? This was talked about at PHP5.5 release, has never happened yet, and doesn't seem planed. This could have a big impact on the engine codebase. I just cant believe we won't rework our API , fully and deeply, for PHP-Next. Julien -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Move phpng to master
Hi We need to consider PHP-Next jump as an opportunity to clean our API and finally have something understandable for a newcomer, and documented. That's a move nobody dared to take in the last decade, degrading more and more our codebase in term of understandability and flexibility. This can't last It's absolutely fine to have separate discussions on cleaning APIs, new features and any other changes people think we should do, but it absolutely has nothing to do with phpng moving into master. We can take the opportunity of a major version to do some cleanups, BUT: 1. It's independent from the phpng effort and RFC. We should vote on it as soon as possible to remove any doubts that do linger in people's minds regarding whether at all we're going to use it. 2. We should set a due date for this version, so that we don't wait indefinitely for things to happen. We don't have the luxury of 'sitting' on phpng for years, IMHO. This too is an independent question from this RFC. I just cant believe we won't rework our API , fully and deeply, for PHP-Next. You're more than welcome to make such proposals and either write patches or rally others to write them. This RFC doesn't preclude any other changes happening in PHP.NEXT, it just removes the doubts about this being the basis for the next version of PHP. Regarding Dmitry saying that phpng is an experimental branch - that was a couple of months ago. It evolved, it runs apps in parity with 5.6, and it's fine to move it to master right now. The alternative - developing 5.7 on master and creating a synchronization hell - sounds like a horrible course of action. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
Am 21.07.2014 10:33, schrieb Zeev Suraski: Regarding Dmitry saying that phpng is an experimental branch - that was a couple of months ago. It evolved, it runs apps in parity with 5.6, and it's fine to move it to master right now. The alternative - developing 5.7 on master and creating a synchronization hell - sounds like a horrible course of action. I was not able to run PHPUnit using PHPNG at all back when it was first announced. I was able to run PHPUnit 4.3 (master)'s test suite using PHPNG last week, btw. Only one test fails (due to a change in the output of print_r() for SplObjectStorage IIRC). This tells me that there was a lot of progress :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On 21/07/2014, Zeev Suraski z...@zend.com wrote: Regarding Dmitry saying that phpng is an experimental branch - that was a couple of months ago. It evolved, it runs apps in parity with 5.6, and it's fine to move it to master right now. Perhaps you could write a summary of what's changed since phpng was uncovered a couple of months ago? (besides better performance and greater compatibility with existing PHP) And also update the existing RFC with the benefits of merging this branch to master, as opposed to describing the inconvenience of not merging it. I'm sure that would help keep the discussion on topic and grounded in fact. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
Hi Julien, Hi I can only agree here. I'd like a clean API. We need to consider PHP-Next jump as an opportunity to clean our API and finally have something understandable for a newcomer, and documented. That's a move nobody dared to take in the last decade, degrading more and more our codebase in term of understandability and flexibility. This can't last I'm more than agree about internal cleanup. phpng benchmark results proved that we take the right direction and now we implemented most the ideas we had. Note that we tried not to change PHP behaviour in any way. Now it's a good time to start the cleanup work. Old features and unused things should be cleaned up. Quickly caught, impacting the engine : - Resources are a hell, mixed with zend_lists etc... inconsitstent and absolutely PITA to develop with. - Streams need to be cleaned up and reworked to support full asynchronous IOs, which could involve threads, thus engine tied - Signals have been worked on starting with 5.4 (AFAIR), but never activated by default. I guess the actual implementation lacks a bit more reflection to be stable, and to finally propose signal managers into userland. ext/pcntl should be somehow merged to core, and this as well would involve engine work - TSRM need to find love, or to find a better replacement, which would involve a big engine work as well - ... and so on Some of the topics above are really big... :) Macro hell should be reworked as inlined functions, and I'd like we start supporting C99 as well. Performance is a userland point. API, doc, and clean things are developers points, and IMO, they are as important. What about merging OPCache to the branch ? This was talked about at PHP5.5 release, has never happened yet, and doesn't seem planed. This could have a big impact on the engine codebase. What do you mean? isn't it already there. I'm also going to remove opcache code for old PHP versions in php-next. I just cant believe we won't rework our API , fully and deeply, for PHP-Next. You and others are welcome. Once we merge phpng into master, we all may cooperate better. Thanks. Dmitry. Julien -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
Hi Zeev, On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski z...@zend.com wrote: As we’re getting closer to release 5.6.0, and given the very high level of interest in phpng, I think it’s time for us to provide some clarity regarding what happens post 5.6.0. Are you willing to have 5.7 branch? It gives us more time to develop/cleanup/test. It's especially important for 3rd party module developers. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: Move phpng to master
On 21 Jul 2014 10:21, Julien Pauli jpa...@php.net wrote: On Mon, Jul 21, 2014 at 9:52 AM, Pierre Joye pierre@gmail.com wrote: hi Zeev, On Mon, Jul 21, 2014 at 9:31 AM, Zeev Suraski z...@zend.com wrote: All, As we’re getting closer to release 5.6.0, and given the very high level of interest in phpng, I think it’s time for us to provide some clarity regarding what happens post 5.6.0. Dmitry and I wrote an RFC proposing that we merge phpng into master and turn it into the basis of the next major version of PHP (name TBD). The RFC is available at https://wiki.php.net/rfc/phpng Some supporting links available down below. Comments welcome! Quoting Dmitry's mail from last week phpng is an experimental branch, as such, I see no appealing reasons to replace master with phpng and use phpng as base for the next major version. I am not really surprised by this request, despite contradictory comments about this exact point in the past few weeks. Despite the excellent performance improvements, it is by far not ready to be used as base for the next major release, the release we will have to maintain for the next decade. There is almost no documentation, the APIs are not clean or inconsistent (just came back home, will provide details later) but having two separate zpp, same area's functions mixing use of zend_char and char (creating hard to catch bugs, not always catch-able at compile time f.e.), no (known) plan about when the experiments will stop and when or how deep the cleanup will be done. In other words, I cannot agree to replace master with phpng, not with its current state and it is definitively not what I could imagine as a base for php-next. A roadmap, undocumented and plan-less development (sorry, but stacking up a couple of % performance improvement has little to nothing to do with designing php-next) is the best way to fail to have what many of our users and developers could expect for php-next. Cheers, -- Pierre Hi I can only agree here. I'd like a clean API. We need to consider PHP-Next jump as an opportunity to clean our API and finally have something understandable for a newcomer, and documented. That's a move nobody dared to take in the last decade, degrading more and more our codebase in term of understandability and flexibility. This can't last Old features and unused things should be cleaned up. Quickly caught, impacting the engine : - Resources are a hell, mixed with zend_lists etc... inconsitstent and absolutely PITA to develop with. - Streams need to be cleaned up and reworked to support full asynchronous IOs, which could involve threads, thus engine tied - Signals have been worked on starting with 5.4 (AFAIR), but never activated by default. I guess the actual implementation lacks a bit more reflection to be stable, and to finally propose signal managers into userland. ext/pcntl should be somehow merged to core, and this as well would involve engine work - TSRM need to find love, or to find a better replacement, which would involve a big engine work as well - ... and so on Macro hell should be reworked as inlined functions, and I'd like we start supporting C99 as well. Performance is a userland point. API, doc, and clean things are developers points, and IMO, they are as important. What about merging OPCache to the branch ? This was talked about at PHP5.5 release, has never happened yet, and doesn't seem planed. This could have a big impact on the engine codebase. I just cant believe we won't rework our API , fully and deeply, for PHP-Next. I don't think that a cleanup is nearly as important as php-ng is as we stand currently. The will be no mercy from the competition. We can start reworking the API when it hit master.
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, 21 Jul 2014, Zeev Suraski wrote: As we’re getting closer to release 5.6.0, and given the very high level of interest in phpng, I think it’s time for us to provide some clarity regarding what happens post 5.6.0. Dmitry and I wrote an RFC proposing that we merge phpng into master and turn it into the basis of the next major version of PHP (name TBD). The RFC is available at https://wiki.php.net/rfc/phpng I was wondering whether there is an extension upgrading guide somewhere? I saw that https://wiki.php.net/phpng-int lists the changes to zvals, but it's not a guide and/or checklist on what to do for upgrading an extension. This, IMO, should include things such as: - which things needs changing - how object instanciation is now different - common pitfalls and errors. - etc. If there isn't such a thing, it's going to be quite necessary for 3rd party extension developers I'd say. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On 21/07/2014 11:13, Sebastian Bergmann wrote: Am 21.07.2014 10:33, schrieb Zeev Suraski: Regarding Dmitry saying that phpng is an experimental branch - that was a couple of months ago. It evolved, it runs apps in parity with 5.6, and it's fine to move it to master right now. The alternative - developing 5.7 on master and creating a synchronization hell - sounds like a horrible course of action. I was not able to run PHPUnit using PHPNG at all back when it was first announced. I was able to run PHPUnit 4.3 (master)'s test suite using PHPNG last week, btw. Only one test fails (due to a change in the output of print_r() for SplObjectStorage IIRC). This tells me that there was a lot of progress :-) I have temporarily re-enabled the phpng jobs on my CI server to assess the current situation. I can confirm that just one test is failing with PHPUnit master. It seems that print_r is not displaying StdClass properties as it used to: https://revive.beccati.com/bamboo/browse/PHP-PHPUN-PHPNG-55/test/case/11800493 On the other hand Doctrine master can't even run the entire test suite due to: Fatal error: Call to a member function getConfiguration() on null in /home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHPNG/tests/Doctrine/Tests/OrmFunctionalTestCase.php on line 482 (pretty sure it's not a null there: a var_dump before the call tells me it's an object) https://revive.beccati.com/bamboo/browse/PHP-DOCTR-PHPNG-52/log The Revive Adserver test suite fails miserably (86+ out of 274 test files), mostly due to errors like: /home/atlassian/bamboo/xml-data/build-dir/PHP-SRC3-BUIL/Zend/zend_hash.c(1369) : ht=0x29c7aa8 is already destroyed and some Call to a member function errors on object variables that are mysteriously seen as null. https://revive.beccati.com/bamboo/browse/REV-LP-PNGP-64 There's lots of legacy code in there and it has proved to be useful in past to catch a few uncommon segmentation faults. I'm pretty sure that there are plenty other applications that can't work with phpng as it is now. To be honest I don't think we're anywhere near the point where it's safe to merge phpng to master. Also, one thing that might have been overlooked is that merging phpng to master would completely bypass the voting phase on https://wiki.php.net/rfc/fast_zpp Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Move phpng to master
-Original Message- From: Matteo Beccati [mailto:p...@beccati.com] Sent: Monday, July 21, 2014 1:08 PM To: internals@lists.php.net Cc: Sebastian Bergmann Subject: Re: [PHP-DEV] RFC: Move phpng to master To be honest I don't think we're anywhere near the point where it's safe to merge phpng to master. Why? People aren't supposed to run production or even development code initially from master. I don't know how many people here were around when PHP 5, 4 and 3 came to be - but when you're dealing with a major version with such massive code changes, you don't get everything right in day one. It will require a community effort - which is exactly what we're trying to achieve here. I don't think that community effort will happen if we don't move it to master and give developers the needed clarity and motivation to work on this. Also, one thing that might have been overlooked is that merging phpng to master would completely bypass the voting phase on https://wiki.php.net/rfc/fast_zpp Our thinking is to use this only for performance sensitive functions that actually move the needle, as opposed to using it across the board - which was the original thinking behind the fast_zpp API. Fast_zpp for this limited set of functions is now a part of phpng; We can decide whether or not we revisit the proposal for using fast_zpp more widely, although as I said in the past, I'm not too fond of the new macro-based APIs myself. For performance sensitive functions that are used a lot, though, I think it makes perfect sense. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Move phpng to master
*From:* yohg...@gmail.com [mailto:yohg...@gmail.com] *On Behalf Of *Yasuo Ohgaki *Sent:* Monday, July 21, 2014 12:32 PM *To:* Zeev Suraski *Cc:* PHP internals *Subject:* Re: [PHP-DEV] RFC: Move phpng to master Hi Zeev, On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski z...@zend.com wrote: As we’re getting closer to release 5.6.0, and given the very high level of interest in phpng, I think it’s time for us to provide some clarity regarding what happens post 5.6.0. Are you willing to have 5.7 branch? It gives us more time to develop/cleanup/test. It's especially important for 3rd party module developers. Can you explain a bit more what you mean by that? I generally don’t think we should invest in another feature release before this next phpng-based major version (that’s my personal thinking). It’ll spread our limited resources too thin; But maybe I didn’t quite understand what you had in mind for putting in the 5.7 branch. Zeev
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 10:33 AM, Zeev Suraski z...@zend.com wrote: It's absolutely fine to have separate discussions on cleaning APIs, new features and any other changes people think we should do, but it absolutely has nothing to do with phpng moving into master. We can take the opportunity of a major version to do some cleanups, BUT: It is obviously not only absolutely fine, it is a requirement. It should have done before anything else, for obvious reasons. 1. It's independent from the phpng effort and RFC. We should vote on it as soon as possible to remove any doubts that do linger in people's minds regarding whether at all we're going to use it. If it is independent from phpng then phpng is nothing more than a (set of) patches that should be proposed independently and not as a replacement for master or as base for php-next. 2. We should set a due date for this version, so that we don't wait indefinitely for things to happen. We don't have the luxury of 'sitting' on phpng for years, IMHO. This too is an independent question from this RFC. I wonder when you have been while we were talking about what we actually like to do and have in php-next. Maybe it was a better strategic choice to participate in the various efforts to get a clear, well discussed and designed roadmap rather than doing this massive set of patches in your corner. And yes, I already said that many times. I just cant believe we won't rework our API , fully and deeply, for PHP-Next. You're more than welcome to make such proposals and either write patches or rally others to write them. This RFC doesn't preclude any other changes happening in PHP.NEXT, it just removes the doubts about this being the basis for the next version of PHP. As a matter of facts, and despite your (team) numerous posts saying that you had no plan to do what you are proposing here, the efforts for php-next has simply being stopped to avoid the pain that was the 64bit RFC because of phpng. A RFC that you totally agreed to have in next as it was earlier this year after having rejecting it for 5.x. Regarding Dmitry saying that phpng is an experimental branch - that was a couple of months ago. That was last week or at the end of the previous week. Amazingly enough, at the same time you were saying that phpng was pretty stable and no more huge changes will happen, many huge changes reached this branch, and these changes were not bugs fixes. It tells me a lot about the visibility you have on phpng. I do not mean to offend anyone here but for what I see here is what we had with opcache, power 20. I do not want to see that for php-next, or we can just begin to vote for what will be the next major version once we borked 6 and 7. It evolved, it runs apps in parity with 5.6, and it's fine to move it to master right now. The alternative - developing 5.7 on master and creating a synchronization hell - sounds like a horrible course of action. Welcome to the world you created for us since you rejected a 200% stable branch and then killing it by introducing an experimental one, with a clear goal, from the very beginning, to replace master for the next major version. This world is not the one I want or wish for the PHP core. Now, enough bashing. What I wish to even consider reviewing or discussing phpng any further: - clear documentation of the changes and migration plans - clear roadmap of upcoming changes, even work in progress - how open you are to changes (cleanup, APIs consistency improvements,etc.) in phpng before it is merged, no matter how - integration of existing patches, blocked now since months by phpng, and how you plan to support us to merge them in phpng, if it ever happens. - actual discussions about what we want for php-next, as performance is only very tiny part of the work for php-next Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 11:37 AM, Michael Wallner m...@php.net wrote: I don't think that a cleanup is nearly as important as php-ng is as we stand currently. The will be no mercy from the competition. We can start reworking the API when it hit master. Cleanup reduces the work, not increase it. Cleanup eases testing, review and maintenance. I am sorry but I totally fail to understand why it is not the absolute top goal for next. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 12:18 PM, Zeev Suraski z...@zend.com wrote: *From:* yohg...@gmail.com [mailto:yohg...@gmail.com] *On Behalf Of *Yasuo Ohgaki *Sent:* Monday, July 21, 2014 12:32 PM *To:* Zeev Suraski *Cc:* PHP internals *Subject:* Re: [PHP-DEV] RFC: Move phpng to master Hi Zeev, On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski z...@zend.com wrote: As we’re getting closer to release 5.6.0, and given the very high level of interest in phpng, I think it’s time for us to provide some clarity regarding what happens post 5.6.0. Are you willing to have 5.7 branch? It gives us more time to develop/cleanup/test. It's especially important for 3rd party module developers. Can you explain a bit more what you mean by that? I generally don’t think we should invest in another feature release before this next phpng-based major version (that’s my personal thinking). It’ll spread our limited resources too thin; But maybe I didn’t quite understand what you had in mind for putting in the 5.7 branch. Zeev He just asks if we will have a 5.7 release while working on the next major in master. I don't think that we can release the php-next under a years, so I think that an 5.7 could be warranted (to keep up with our roadmap), but depends on wether or not we have enough new (BC-safe) features. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] RFC: Move phpng to master
Hi Zeev, On Mon, Jul 21, 2014 at 12:16 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Matteo Beccati [mailto:p...@beccati.com] Sent: Monday, July 21, 2014 1:08 PM To: internals@lists.php.net Cc: Sebastian Bergmann Subject: Re: [PHP-DEV] RFC: Move phpng to master To be honest I don't think we're anywhere near the point where it's safe to merge phpng to master. Why? People aren't supposed to run production or even development code initially from master. I don't know how things are driven here, but I assume that OSS projects don't merge stuff into master until tests pass: it's as simple as that. That's your blocker right there, regardless of voting or any other discussion going on. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 11:27 AM, Dmitry Stogov dmi...@zend.com wrote: Hi Julien, Hi I can only agree here. I'd like a clean API. We need to consider PHP-Next jump as an opportunity to clean our API and finally have something understandable for a newcomer, and documented. That's a move nobody dared to take in the last decade, degrading more and more our codebase in term of understandability and flexibility. This can't last I'm more than agree about internal cleanup. phpng benchmark results proved that we take the right direction and now we implemented most the ideas we had. Note that we tried not to change PHP behaviour in any way. Now it's a good time to start the cleanup work. Not changing behavior is nice and very hard work to do, so congrats on that one. If cleaning the API receives no-go because the cleanups would involve swaping some parameters in functions, or turning macros to inline functions , which drops some little percentage in performance on some rare compilers, then there will be a problem to me. We need a trade-off here. We can't leave unreadable code in, should this code be written in a specific way for performances. We can afford a little 1% or 2 IMO. Old features and unused things should be cleaned up. Quickly caught, impacting the engine : - Resources are a hell, mixed with zend_lists etc... inconsitstent and absolutely PITA to develop with. - Streams need to be cleaned up and reworked to support full asynchronous IOs, which could involve threads, thus engine tied - Signals have been worked on starting with 5.4 (AFAIR), but never activated by default. I guess the actual implementation lacks a bit more reflection to be stable, and to finally propose signal managers into userland. ext/pcntl should be somehow merged to core, and this as well would involve engine work - TSRM need to find love, or to find a better replacement, which would involve a big engine work as well - ... and so on Some of the topics above are really big... :) Macro hell should be reworked as inlined functions, and I'd like we start supporting C99 as well. Performance is a userland point. API, doc, and clean things are developers points, and IMO, they are as important. What about merging OPCache to the branch ? This was talked about at PHP5.5 release, has never happened yet, and doesn't seem planed. This could have a big impact on the engine codebase. What do you mean? isn't it already there. I'm also going to remove opcache code for old PHP versions in php-next. I was talking about merging the code bases. For example, shared memory model from OPCache could be merged into Zend/ and expose an API one could reuse in extensions needing SHM. Also, accelerator's code could be merged into Zend/zend_execute and Zend/ZendVM Julien -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Move phpng to master
I don't know how things are driven here, but I assume that OSS projects don't merge stuff into master until tests pass: it's as simple as that. That's your blocker right there, regardless of voting or any other discussion going on. There’s a huge difference between a major code changes as we line up for a new major version – one that requires widespread testing and community support – and the relatively minor changes we’ve had here ever since PHP 5. So from my POV at least, that assumption is incorrect. Zeev
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 12:24 PM, Ferenc Kovacs tyr...@gmail.com wrote: He just asks if we will have a 5.7 release while working on the next major in master. I don't think that we can release the php-next under a years, so I think that an 5.7 could be warranted (to keep up with our roadmap), but depends on wether or not we have enough new (BC-safe) features. Clearly yes, for two reasons: - we do one x.y+1 every year - php-next will take 2-3 years, ideally (while I have doubts when I see what is going on now) Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Move phpng to master
He just asks if we will have a 5.7 release while working on the next major in master. I don't think that we can release the php-next under a years, so I think that an 5.7 could be warranted (to keep up with our roadmap), but depends on wether or not we have enough new (BC-safe) features. I don’t see a reason of why we can’t have this major version ready by or even sooner than the current yearly rhythm we have. In fact, if we do aim to work in parallel on both 5.7 and .NEXT – we’re likely to needlessly delay .NEXT… Zeev
Re: [PHP-DEV] RFC: Move phpng to master
On Mon, Jul 21, 2014 at 12:30 PM, Zeev Suraski z...@zend.com wrote: There’s a huge difference between a major code changes as we line up for a new major version – one that requires widespread testing and community support – and the relatively minor changes we’ve had here ever since PHP 5. So from my POV at least, that assumption is incorrect. We provide an extensive test suite (for every project) which can be run by anyone, and you are getting my feedback for it right now ;-) Matteo was also nice to set up a PHPNG environment where D2 tests are run, so you can have continuous feedback as well. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
