# [VOTE] Move the phpng branch to master - Thread: https://externals.io/message/76376 - Original archive: https://news-web.php.net/php.internals/76376 - Started by Zeev Suraski on 2014-08-06T12:36:03+00:00 - Messages: 27 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/76376.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #76376 — Zeev Suraski — 2014-08-06T12:36:03+00:00 URL: https://externals.io/message/76376#76376 I opened the voting on the phpng RFC: https://wiki.php.net/rfc/phpng#vote Voting ends on Thursday, August 14th. Please vote! Zeev --- ## #76377 — Andrea Faulds — 2014-08-06T12:38:53+00:00 URL: https://externals.io/message/76376#76377 · In reply to: #76376 > I opened the voting on the phpng RFC: > > > > https://wiki.php.net/rfc/phpng#vote > > > > Voting ends on Thursday, August 14th. I voted Yes, but I have to ask: Is there anything in master that’s not in phpng, i.e., is it completely up-to-date with the current master? Also, how are you guys doing with extension and SAPI support? Does phpdbg compile yet? (That’s particularly bugged me, I like having phpdbg because now I can view opcodes without needing vld, but it seems to be broken in ng.) -- Andrea Faulds http://ajf.me/ --- ## #76379 — Jonny Stirling — 2014-08-06T12:47:50+00:00 URL: https://externals.io/message/76376#76379 · In reply to: #76376 Zeev, I love how you've just completely ignored any previous discussion around the required majority issue. It's is certainly enlightening that questions specifically directed at you in multiple threads have gone unanswered when trying to work out which is actually required. Instead, you just take it on yourself to decide for everyone else. That's consideration for you. I mean, everybody else is wrong, right, so why worry about anything they say. My hat's (sarcastically) off to you sir. Jonny. P.s. Is this post un-useful? Perhaps. But it's not like a mail not infested with sarcasm is going make much difference. --- ## #76380 — Pierre Joye — 2014-08-06T12:49:59+00:00 URL: https://externals.io/message/76376#76380 · In reply to: #76377 hi Zeev, > > > > > […] > > I voted Yes, but I have to ask: Is there anything in master that’s not in phpng, i.e., is it completely up-to-date with the current master? > > Also, how are you guys doing with extension and SAPI support? Does phpdbg compile yet? (That’s particularly bugged me, I like having phpdbg because now I can view opcodes without needing vld, but it seems to be broken in ng.) As I am indeed in favor of having it in master sooner rather than later I really have a bad feeling about it right now. None of the questions I asked have been answered, like what is your roadmap? Pushing hard again to get the one year dev time for 7? The phpng RFC (and related pages) are not in a state where we could simply say yes to phpng without the risk to get things in we do not want (like the new argument parsing which is still in this branch). All in all, I all for moving phpng to master but not at this point, there are way too many unanswered questions and many of them are more than critical. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #76381 — Andrea Faulds — 2014-08-06T12:50:42+00:00 URL: https://externals.io/message/76376#76381 · In reply to: #76379 > I love how you've just completely ignored any previous discussion around > the required majority issue. Has it really been *ignored*? Just because someone wants something doesn’t mean you have to give it. Under Zeev’s (and as it so happens, my) interpretation of the voting process RFC, this does not need a 2/3 majority. phpng is not a language change, it is an implementation detail. Now, could Zeev make it have a 2/3 majority to be less controversial? Sure, but he doesn’t have to. -- Andrea Faulds http://ajf.me/ --- ## #76382 — Dmitry Stogov — 2014-08-06T12:52:15+00:00 URL: https://externals.io/message/76376#76382 · In reply to: #76377 Hi Andrea, > > > > > […] > > I voted Yes, but I have to ask: Is there anything in master that’s not in > phpng, i.e., is it completely up-to-date with the current master? > I made synchronization on this week. The very last master commits might be not in phpng yet. PHPNG must contain all the things from the master. > > Also, how are you guys doing with extension and SAPI support? Porting missing extensions and SAPIs is not in our priority list. We may provide some help for maintainers, but we are not going to do everything ourselves. > Does phpdbg compile yet? (That’s particularly bugged me, I like having > phpdbg because now I can view opcodes without needing vld, but it seems to > be broken in ng.) > We didn't port it. Thanks. Dmitry. > > -- > Andrea Faulds > http://ajf.me/ --- ## #76383 — Ferenc Kovacs — 2014-08-06T12:52:47+00:00 URL: https://externals.io/message/76376#76383 · In reply to: #76377 > > > > > […] > > I voted Yes, but I have to ask: Is there anything in master that’s not in > phpng, i.e., is it completely up-to-date with the current master? > master was last merged into phpng in http://git.php.net/?p=php-src.git;a=commit;h=7301994c28d548c5a4eda6a3a4ae0fab6af04636 two days ago. > > Also, how are you guys doing with extension and SAPI support? Does phpdbg > compile yet? (That’s particularly bugged me, I like having phpdbg because > now I can view opcodes without needing vld, but it seems to be broken in > ng.) > https://wiki.php.net/phpng#supported_sapi https://wiki.php.net/phpng#supported_extensions these are only the exts/sapis in the core, I think that adding support to the pecl exts should be a community effort. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #76384 — Derick Rethans — 2014-08-06T12:57:09+00:00 URL: https://externals.io/message/76376#76384 · In reply to: #76382 > > > > […] > > […] > > Porting missing extensions and SAPIs is not in our priority list. We > may provide some help for maintainers, but we are not going to do > everything ourselves. That's ok - how are the porting guidelines coming along though? > > […] > > We didn't port it. VLD works though ;-) cheers, Derick --- ## #76385 — Zeev Suraski — 2014-08-06T12:59:24+00:00 URL: https://externals.io/message/76376#76385 · In reply to: #76381 > -----Original Message----- > From: Andrea Faulds [mailto:ajf@ajf.me] > Sent: Wednesday, August 06, 2014 3:51 PM > To: Jonny Stirling > Cc: Zeev Suraski; PHP internals > Subject: Re: [PHP-DEV] [VOTE] Move the phpng branch to master > > > On 6 Aug 2014, at 13:47, Jonny Stirling wrote: > > > […] > > Has it really been *ignored*? Just because someone wants something doesn't > mean you have to give it. > > Under Zeev's (and as it so happens, my) interpretation of the voting process > RFC, this does not need a 2/3 majority. phpng is not a language change, it is an > implementation detail. Fully agree with Andrea. I don't think there's a point in debating the majority question to no end, because ultimately, it's open for interpretation. I feel very, very confident about my interpretation - for reasons I explained already. I didn't ignore the feedback, I disagreed with it. > Now, could Zeev make it have a 2/3 majority to be less controversial? Sure, > but he doesn't have to. I still stand by my original comment - that I hope and believe this RFC will get well over 2/3 - but that it technically only requires a simple majority. Zeev --- ## #76386 — Dan Ackroyd — 2014-08-06T13:00:54+00:00 URL: https://externals.io/message/76376#76386 · In reply to: #76376 Hi, It would be good if people announced that they were going to open things to vote with a warning, rather than just throwing the voting open. The RFC is nowhere complete in it's details for people to make rational decisions. e.g. the section on 'RFC impact' has this for the impact on extensions. "Existing extensions will have to be updated to reflect the new data structures and updated APIs. Much of this work is already done for most of the extensions bundled with PHP, but there are still extensions that need to be ported, and most of the extensions in PECL will have to be ported." That doesn't provide anything close to actual information about what needs to be done to port the extensions. There is no information about how extensions can support current PHP and PHPNG at the same time....which they will need to do for the next couple of years at least. cheers Dan > I opened the voting on the phpng RFC: > > > > https://wiki.php.net/rfc/phpng#vote > > > > Voting ends on Thursday, August 14th. > > > > Please vote! > > > > Zeev --- ## #76387 — Pierre Joye — 2014-08-06T13:07:03+00:00 URL: https://externals.io/message/76376#76387 · In reply to: #76385 > Fully agree with Andrea. I don't think there's a point in debating the > majority question to no end, because ultimately, it's open for > interpretation. I feel very, very confident about my interpretation - for > reasons I explained already. I didn't ignore the feedback, I disagreed > with it. You disagree with questions? I call that self censorship. Very good lead. > > […] > Sure, > > […] > > I still stand by my original comment - that I hope and believe this RFC > will get well over 2/3 - but that it technically only requires a simple > majority. A total rewamp of the engine, with some part of it being very disputable, some even had draft RFCs but looks like feedback for them are being ignored as well, and some BC as bonus? This requires 2/3. Period. And you will certainly get them, don't worry. And that's quite depressing about what's going on in php.net lately. -- Pierre @pierrejoye | http://www.libgd.org --- ## #76389 — Zeev Suraski — 2014-08-06T13:11:32+00:00 URL: https://externals.io/message/76376#76389 · In reply to: #76386 Dan, Votes area almost never pre-announced. I have no problem with changing this habit, but I do have an issue with changing it retroactively for a particular vote. Regarding your points, there's a mandatory discussion period during which you should have brought these comments, instead of now. As a matter of fact, discussion about PHPNG died out more than a week ago, to the level that Dmitry even suggested we avoid wasting time and vote sooner (but that goes against the rules so we didn't do that). If you think the RFC is incomplete in its details and that you can't vote over it then you can of course withhold your vote or vote no. To your specific feedback, there's a migration document to extensions linked from the RFC, and shared here on internals about 10 days ago: https://wiki.php.net/phpng-upgrading I added another link to it from the 'RFC impact' section, as perhaps that's what prevented you from seeing it. I believe it's impractical to keep shared codebases for extensions between PHP 5.x and PHPNG. Dmitry - please correct me if I'm wrong... Zeev > -----Original Message----- > From: Dan Ackroyd [mailto:danack@basereality.com] > Sent: Wednesday, August 06, 2014 4:01 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] [VOTE] Move the phpng branch to master > > Hi, > > It would be good if people announced that they were going to open things > to > vote with a warning, rather than just throwing the voting open. > > The RFC is nowhere complete in it's details for people to make rational > decisions. e.g. the section on 'RFC impact' has this for the impact on > extensions. > > "Existing extensions will have to be updated to reflect the new data > structures > and updated APIs. Much of this work is already done for most of the > extensions bundled with PHP, but there are still extensions that need to > be > ported, and most of the extensions in PECL will have to be ported." > > That doesn't provide anything close to actual information about what needs > to > be done to port the extensions. There is no information about how > extensions > can support current PHP and PHPNG at the same time....which they will need > to do for the next couple of years at least. > > > cheers > Dan > > > > > […] --- ## #76390 — Zeev Suraski — 2014-08-06T13:12:20+00:00 URL: https://externals.io/message/76376#76390 · In reply to: #76384 > -----Original Message----- > From: Derick Rethans [mailto:derick@php.net] > Sent: Wednesday, August 06, 2014 3:57 PM > To: Dmitry Stogov > Cc: Andrea Faulds; Zeev Suraski; PHP internals > Subject: Re: [PHP-DEV] [VOTE] Move the phpng branch to master > > That's ok - how are the porting guidelines coming along though? https://wiki.php.net/phpng-upgrading Not too bad for this stage I think... Zeev --- ## #76391 — Dmitry Stogov — 2014-08-06T13:19:46+00:00 URL: https://externals.io/message/76376#76391 · In reply to: #76389 > Dan, > > Votes area almost never pre-announced. I have no problem with changing > this > habit, but I do have an issue with changing it retroactively for a > particular vote. > > Regarding your points, there's a mandatory discussion period during which > you should have brought these comments, instead of now. As a matter of > fact, discussion about PHPNG died out more than a week ago, to the level > that Dmitry even suggested we avoid wasting time and vote sooner (but that > goes against the rules so we didn't do that). > > If you think the RFC is incomplete in its details and that you can't vote > over it then you can of course withhold your vote or vote no. > > To your specific feedback, there's a migration document to extensions > linked > from the RFC, and shared here on internals about 10 days ago: > https://wiki.php.net/phpng-upgrading > I added another link to it from the 'RFC impact' section, as perhaps that's > what prevented you from seeing it. > > I believe it's impractical to keep shared codebases for extensions between > PHP 5.x and PHPNG. Dmitry - please correct me if I'm wrong... > Some extension might require just few changes and they may share codebase for PHP and PHPNG, however it's going to be really difficult for very engine depended extensions like xdebug. Thanks. Dmitry. > > Zeev > > > […] > needs > > […] > need > > […] --- ## #76392 — Lester Caine — 2014-08-06T13:21:54+00:00 URL: https://externals.io/message/76376#76392 · In reply to: #76389 > I believe it's impractical to keep shared codebases for extensions between > PHP 5.x and PHPNG. Dmitry - please correct me if I'm wrong... Do we actually have a list of what is NOT going to work once this happens? I am still not in a position to test phpng myself simply because I rely on extensions that have not been ported yet and despite trying to work through all the new documentation I can't see as yet how I could do that work myself :( -- 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 --- ## #76393 — Pierre Joye — 2014-08-06T13:26:08+00:00 URL: https://externals.io/message/76376#76393 · In reply to: #76391 > > > > […] > > Some extension might require just few changes and they may share codebase > for PHP and PHPNG, however it's going to be really difficult for very > engine depended extensions like xdebug. For the exts I tried while I was testing/fixing phpng a couple of weeks ago, I'd to say that maintaining the same code base for phpng and 5.x is simply too hard, way too many APIs changes, many of them cannot be detected at compile time, introducing many many new #ifdefs along other things. I will maintain a separate branch. The only thing I worry about is how I will manage releases in pecl. I have no clean solution now, or maybe one release with two branches bundled. Separate releases could work too but I will try everything possible to do not have to do that, or to have to do that as it is really painful to do. Maybe I can manage to implement something in pickle to ease this work. Ideas welcome. -- Pierre @pierrejoye | http://www.libgd.org --- ## #76394 — Andrea Faulds — 2014-08-06T13:45:56+00:00 URL: https://externals.io/message/76376#76394 · In reply to: #76393 > For the exts I tried while I was testing/fixing phpng a couple of > weeks ago, I'd to say that maintaining the same code base for phpng > and 5.x is simply too hard, way too many APIs changes, many of them > cannot be detected at compile time, introducing many many new #ifdefs > along other things. I will maintain a separate branch. The only thing > I worry about is how I will manage releases in pecl. I have no clean > solution now, or maybe one release with two branches bundled. Separate > releases could work too but I will try everything possible to do not > have to do that, or to have to do that as it is really painful to do. > Maybe I can manage to implement something in pickle to ease this work. > Ideas welcome. Perhaps for these extensions, it is best to not make it work with both versions, but instead have a 5.x version and a phpng version, and continue to maintain both separately? I wonder if that might actually be less work than trying to keep a single version working on both. -- Andrea Faulds http://ajf.me/ --- ## #76395 — Pierre Joye — 2014-08-06T13:54:25+00:00 URL: https://externals.io/message/76376#76395 · In reply to: #76394 > > > > > […] > > Perhaps for these extensions, it is best to not make it work with both versions, but instead have a 5.x version and a phpng version, and continue to maintain both separately? I wonder if that might actually be less work than trying to keep a single version working on both. This is what I just said. But the problem is then how to release them. An extension will release 2.0.0, how do you release it? 2.0.0-7 and 2.0.0 for 5.x? Packaging, branching, etc. will be painful too. The whole flow many projects uses now will have to change. This is something I have to think about, not sure what is the best solution yet. -- Pierre @pierrejoye | http://www.libgd.org --- ## #76398 — Dan Ackroyd — 2014-08-06T15:38:05+00:00 URL: https://externals.io/message/76376#76398 · In reply to: #76389 Hi Zeev, >I have no problem with changing this >habit, but I do have an issue with changing it retroactively for a >particular vote. Agreed, changing rules retroactively is bad. Considering improving practices for the future is good. >To your specific feedback, there's a migration document to extensions linked >from the RFC, and shared here on internals about 10 days ago: Thanks for that document. It would also be really useful if you could add a link to two commits of a non-trivial extension that has been migrated, with one commit before, and one commit after the migration. That would allow people like myself who only rarely dip into PHP internals to see the differences actually applied to code. cheers Dan > Dan, > > Votes area almost never pre-announced. I have no problem with changing this > habit, but I do have an issue with changing it retroactively for a > particular vote. > > Regarding your points, there's a mandatory discussion period during which > you should have brought these comments, instead of now. As a matter of > fact, discussion about PHPNG died out more than a week ago, to the level > that Dmitry even suggested we avoid wasting time and vote sooner (but that > goes against the rules so we didn't do that). > > If you think the RFC is incomplete in its details and that you can't vote > over it then you can of course withhold your vote or vote no. > > To your specific feedback, there's a migration document to extensions linked > from the RFC, and shared here on internals about 10 days ago: > https://wiki.php.net/phpng-upgrading > I added another link to it from the 'RFC impact' section, as perhaps that's > what prevented you from seeing it. > > I believe it's impractical to keep shared codebases for extensions between > PHP 5.x and PHPNG. Dmitry - please correct me if I'm wrong... > > Zeev > > > […] --- ## #76399 — Ferenc Kovacs — 2014-08-06T15:50:55+00:00 URL: https://externals.io/message/76376#76399 · In reply to: #76398 > Hi Zeev, > > > […] > > Agreed, changing rules retroactively is bad. Considering improving > practices for the future is good. > > > […] > linked > > […] > > Thanks for that document. > > It would also be really useful if you could add a link to two commits > of a non-trivial extension that has been migrated, with one commit > before, and one commit after the migration. That would allow people > like myself who only rarely dip into PHP internals to see the > differences actually applied to code. > git diff origin/master.. -- ext/curl (for example) is this really something which you think most voters would have trouble doing? -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #76400 — Ferenc Kovacs — 2014-08-06T15:52:35+00:00 URL: https://externals.io/message/76376#76400 · In reply to: #76399 > > > > On Wed, Aug 6, 2014 at 5:38 PM, Dan Ackroyd > wrote: > > > […] > > git diff origin/master.. -- ext/curl (for example) > is this really something which you think most voters would have trouble > doing? > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > git diff origin/master..origin/phpng -- ext/curl is slightly better as it works independently from the current checkout. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #76401 — Dmitry Stogov — 2014-08-06T15:59:30+00:00 URL: https://externals.io/message/76376#76401 · In reply to: #76398 hi Dan, you can look into the difference for each particular extension using git. e.g. git diff master..phpng -- ext/bcmath Thanks. Dmitry. > Hi Zeev, > > > […] > > Agreed, changing rules retroactively is bad. Considering improving > practices for the future is good. > > > […] > linked > > […] > > Thanks for that document. > > It would also be really useful if you could add a link to two commits > of a non-trivial extension that has been migrated, with one commit > before, and one commit after the migration. That would allow people > like myself who only rarely dip into PHP internals to see the > differences actually applied to code. > > > cheers > Dan > > > > > […] > this > > […] > that > > […] > linked > > […] > that's > > […] > between > > […] > needs > > […] > need > > […] --- ## #76405 — Christian Stoller — 2014-08-07T06:13:02+00:00 URL: https://externals.io/message/76376#76405 · In reply to: #76395 From: Pierre Joye [mailto:pierre.php@gmail.com] > > > […] > > This is what I just said. But the problem is then how to release them. > An extension will release 2.0.0, how do you release it? 2.0.0-7 and > 2.0.0 for 5.x? Packaging, branching, etc. will be painful too. The > whole flow many projects uses now will have to change. This is > something I have to think about, not sure what is the best solution > yet. > > -- > Pierre I'd say the best way is to create a new major version for the extension branch which works with phpng. So 2.0.0 for normal and 3.0.0 for phpng. This would make it possible to maintain two branches for both versions. But I don't know if this is possible with pecl. Christian --- ## #76406 — Pierre Joye — 2014-08-07T10:57:00+00:00 URL: https://externals.io/message/76376#76406 · In reply to: #76405 > > From: Pierre Joye [mailto:pierre.php@gmail.com] > > […] actually > > […] > > I'd say the best way is to create a new major version for the extension > branch which works with phpng. > So 2.0.0 for normal and 3.0.0 for phpng. This would make it possible > to maintain two branches for both versions. But I don't know if this is possible > with pecl. Not sure. It means 5.x versions won't get any major version then, which is very unlikely for many exts. Cheers, Pierre --- ## #76458 — Levi Morrison — 2014-08-12T23:01:17+00:00 URL: https://externals.io/message/76376#76458 · In reply to: #76406 This is a just a reminder that voting ends on Thursday, August 14th. --- Next page: https://externals.io/message/76376.md?page=2