I opened the voting on the phpng RFC:
https://wiki.php.net/rfc/phpng#vote
Voting ends on Thursday, August 14th.
Please vote!
Zeev
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/
hi Zeev,
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.)
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
Hi Andrea,
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?
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/
<snip>I opened the voting on the phpng RFC:
https://wiki.php.net/rfc/phpng#vote
Voting ends on Thursday, August 14th.
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.
That's ok - how are the porting guidelines coming along though?
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.
VLD works though ;-)
cheers,
Derick
-----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 masterThat'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
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?
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
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.
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/
-----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 masterOn 6 Aug 2014, at 13:47, Jonny Stirling phoenix@jonstirling.co.uk
wrote: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.
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
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.
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.
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
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
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 masterHi,
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
DanI opened the voting on the phpng RFC:
https://wiki.php.net/rfc/phpng#vote
Voting ends on Thursday, August 14th.
Please vote!
Zeev
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
-----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 masterHi,
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
DanI opened the voting on the phpng RFC:
https://wiki.php.net/rfc/phpng#vote
Voting ends on Thursday, August 14th.
Please vote!
Zeev
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.
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
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/
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.
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
From: Pierre Joye [mailto:pierre.php@gmail.com]
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.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
From: Pierre Joye [mailto:pierre.php@gmail.com]
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.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.--
PierreI'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
This is a just a reminder that voting ends on Thursday, August 14th.
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
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
-----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 masterHi,
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
DanI opened the voting on the phpng RFC:
https://wiki.php.net/rfc/phpng#vote
Voting ends on Thursday, August 14th.
Please vote!
Zeev
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.
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
On Wed, Aug 6, 2014 at 5:38 PM, Dan Ackroyd danack@basereality.com
wrote: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.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
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,
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
DanDan,
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 masterHi,
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
DanI opened the voting on the phpng RFC:
https://wiki.php.net/rfc/phpng#vote
Voting ends on Thursday, August 14th.
Please vote!
Zeev
Le 06/08/2014 14:36, Zeev Suraski a écrit :
I opened the voting on the phpng RFC:
https://wiki.php.net/rfc/phpng#vote
Voting ends on Thursday, August 14th.
After speaking with other members of AFUP (French user-group) about this
RFC, here's a short summary of our thoughts:
The idea of (greatly: 20-30%) improving performances is really
interesting, be it for performances themselves or for the reputation of
the language.
That's even more true if this gets us closer to JIT in the future.
Having to update all extensions is not "perfect", but is not really a
problem either: developers of extensions know this is to be expected for
each major version of PHP -- and, after the branch is merged to master,
they will still have something like two years to update their extensions.
We are a bit sad this has been developed for quite some time in secret
and the community has learned about it only after most of the work had
been done: it doesn't really fit with the way we think about "open-source".
Same thing about the fact several evolutions have all been worked on in
the same branch, the same RFC and the same vote, instead of each being
independent from the others.
We feel there might have been too much "public" communication about
"phpng" and its performance improvements, before the decision of merging
it was (or not) taken.
Because of this, at the time of the vote, we kind of feel like we don't
have much of a choice: if the branch is not merged, PHP will look quite
ridiculous, as "phpng" is already expected by many to be used as a a
first step for PHP 7.
Judging from some discussions here, we are afraid the quality and
maintainability of PHP's source code might suffer a bit from this merge.
For us, a major version is the right time (it's going to be used for
something like 10 years) to work on those. (still, easy to say, when
only a few of us contribute code to PHP).
PHP 7 will be a "major" version.
It must not be released earlier than planned only to publish some
performance improvements as soon as possible (even if those are great).
It is important to also think about features, reworks and other major
improvements: with one major versions every 10 years, it's pretty much
now or never!
We would prefer PHP 7 to be released as a great version in two years,
rather than seeing it too early in one year.
In the end, there have been two opposite opinions on our UG's
mailing-list -- and both are well represented, with strong posts on both
"yes merge" and "no don't merge":
- Some of us are OK to merge right now and improve things later,
- While others would prefer to improve things now and merge only after.
In any case, we all agree there is still a lot to be done before
reaching PHP 7 ;-)
--
Pascal MARTIN
http://blog.pascal-martin.fr
@pascal_martin
Hi,
According to voting result, phpng was merged into master and the version
number was bumped to 7.0.0-dev.
Thanks to contributors, testers, bloggers, voters and everyone evolved :)
Thanks. Dmitry.
I opened the voting on the phpng RFC:
https://wiki.php.net/rfc/phpng#vote
Voting ends on Thursday, August 14th.
Please vote!
Zeev