Based on the overwhelming response, the vote is now open J
https://wiki.php.net/rfc/optimizerplus
Voting ends March 7th.
Zeev
+1
Based on the overwhelming response, the vote is now open J
https://wiki.php.net/rfc/optimizerplus
Voting ends March 7th.
Zeev
--
Alberto Guimarães Viana
E-mail: albertogviana@gmail.com
http://blog.albertoviana.com
"Uma pessoa inteligente resolve um problema, um sábio o previne." Albert
Einstein
Zeev et al,
I just want to put my justification for the "only if no delay" vote. I
voted that way because we're already at a significant delay. If this vote
was a month ago when O+ was suggested first, I would definitely have voted
for "delay". In fact IIRC I proposed a delay back then. But after a month,
I think delaying much further would be imprudent.
Just my $0.02
Anthony
On Wed, Feb 27, 2013 at 11:24 AM, Alberto Viana albertogviana@gmail.comwrote:
+1
Based on the overwhelming response, the vote is now open J
https://wiki.php.net/rfc/optimizerplus
Voting ends March 7th.
Zeev
--
Alberto Guimarães Viana
E-mail: albertogviana@gmail.com
http://blog.albertoviana.com"Uma pessoa inteligente resolve um problema, um sábio o previne." Albert
Einstein
Zeev et al,
I just want to put my justification for the "only if no delay" vote. I voted that way because we're already at a significant delay. If this vote was a month ago when O+ was suggested first, I would definitely have voted for "delay". In fact IIRC I proposed a delay back then. But after a month, I think delaying much further would be imprudent.
Fair enough! Here's mine for delaying:
I believe our users will much appreciate a release with an opcode
cache that's several months delayed vs. one that's without an opcode
cache several months early. If the 5.4 adoption rate (or complete
lack thereof) is any indication - very few are eagerly waiting for
5.5. In fact, in a year's time, when we all gear up to release 5.6
(based on current frequency) - 5.5 is almost guaranteed to have next
to no traction in our userbase. A bundled opcode cache might be the
killer feature that makes the difference.
FWIW I think we should actually reconsider even striving for a yearly
release cycle, but that's another story...
Zeev
Zeev et al,
I just want to put my justification for the "only if no delay" vote. I voted that way because we're already at a significant delay. If this vote was a month ago when O+ was suggested first, I would definitely have voted for "delay". In fact IIRC I proposed a delay back then. But after a month, I think delaying much further would be imprudent.
Fair enough! Here's mine for delaying:
I believe our users will much appreciate a release with an opcode
cache that's several months delayed vs. one that's without an opcode
cache several months early. If the 5.4 adoption rate (or complete
lack thereof) is any indication - very few are eagerly waiting for
5.5. In fact, in a year's time, when we all gear up to release 5.6
(based on current frequency) - 5.5 is almost guaranteed to have next
to no traction in our userbase. A bundled opcode cache might be the
killer feature that makes the difference.
I agree with zeev here. The opcode cache is one of the most important
thing for adoption. With apc not being 5.4 compatible and 5.3 eol with 5.6,
there is no real transition for people relying on an opcode cache if we don't
delay 5.5. That's the only reason why Julien and I so far delayed it.
Based on the overwhelming response, the vote is now open J
https://wiki.php.net/rfc/optimizerplus
Voting ends March 7th.
Zeev
Hi Zeev,
I'm not sure that the current options covering all cases.
How should one vote if he/she thinks that this should go into the next
release after 5.5?
Currently their only option would be to vote for no, which isn't doesn't
really the same thing.
Personally I would prefer roll out 5.5 without O+, but release it in PECL
for all supported branches and move it for core in master(which means
having it in 5.6/6.0/whatever will be the next version).
Currently I don't have an option which I'm comfortable with, maybe there
are others in the similar situation.
ps: I really love what you guys did with opensourcing it, but I just think
that it is too late for 5.5 and I think that it is better to stick to the
original roadmap, instead of having a 6 months delay just to ship the O+ in
the core 6months earlier than the next version after 5.5 would be shipped
if we would have followed the yearly release plan in the first place.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
ps: I really love what you guys did with opensourcing it, but I just think
that it is too late for 5.5 and I think that it is better to stick to the
original roadmap, instead of having a 6 months delay just to ship the O+ in
the core 6months earlier than the next version after 5.5 would be shipped
if we would have followed the yearly release plan in the first place.
This is where I think we have a big disconnect. This yearly release plan
is meaningless for most people because there is no way the current
opcode cache situation can keep up with that. PHP 5.4 wasn't really
released until APC was mostly stable with it which was 6+ months after
the release. This is the most urgent thing we need to fix in the PHP
world. Everything else in this 5.5 release is irrelevant as far as I am
concerned and we are pushing because of an arbitrary deadline that is
tighter than most previous releases.
In order to actually get the project onto a feasible yearly release
cycle we need to pool the few resources we do have around a single
opcode cache implementation and push it as the one and only option as it
will force each new shiny feature to tackle opcode support from day one
as opposed to circling back around to it as an afterthought as has
happened so often. And no, time has proven that this can't be done by
having it in pecl. It didn't work for APC despite me trying to push that
and I don't see why it would work for O+.
Note that if you take the PHP 5.4 release date as the date APC started
working reliably with it, we are well within the yearly release cycle
and not actually late at all.
-Rasmus
ps: I really love what you guys did with opensourcing it, but I just
think
that it is too late for 5.5 and I think that it is better to stick to the
original roadmap, instead of having a 6 months delay just to ship the O+
in
the core 6months earlier than the next version after 5.5 would be shipped
if we would have followed the yearly release plan in the first place.This is where I think we have a big disconnect. This yearly release plan
is meaningless for most people because there is no way the current
opcode cache situation can keep up with that. PHP 5.4 wasn't really
released until APC was mostly stable with it which was 6+ months after
the release. This is the most urgent thing we need to fix in the PHP
world. Everything else in this 5.5 release is irrelevant as far as I am
concerned and we are pushing because of an arbitrary deadline that is
tighter than most previous releases.In order to actually get the project onto a feasible yearly release
cycle we need to pool the few resources we do have around a single
opcode cache implementation and push it as the one and only option as it
will force each new shiny feature to tackle opcode support from day one
as opposed to circling back around to it as an afterthought as has
happened so often. And no, time has proven that this can't be done by
having it in pecl. It didn't work for APC despite me trying to push that
and I don't see why it would work for O+.
All these are really great arguments for including O+ ... in PHP 5.6. O+ is
already compatible with PHP 5.5 and as we're just days away from feature
freeze this will stay so til the final release ("stay so" as in requiring
only minor adjustments). For 5.6 it can then be merged so that we'll be
forced to maintain the opcode cache along the way when doing new engine
changes.
Nikita
All these are really great arguments for including O+ ... in PHP 5.6. O+ is
already compatible with PHP 5.5 and as we're just days away from feature
freeze this will stay so til the final release ("stay so" as in requiring
only minor adjustments). For 5.6 it can then be merged so that we'll be
forced to maintain the opcode cache along the way when doing new engine
changes.Nikita
What will people use as an opcode cache for 5.4?
Adam
All these are really great arguments for including O+ ... in PHP 5.6. O+ is
already compatible with PHP 5.5 and as we're just days away from feature
freeze this will stay so til the final release ("stay so" as in requiring
only minor adjustments). For 5.6 it can then be merged so that we'll be
forced to maintain the opcode cache along the way when doing new engine
changes.Nikita
What will people use as an opcode cache for 5.4?
Adam
Sorry, typo, I meant to say 5.5.
Adam
On Wed, Feb 27, 2013 at 10:43 PM, Adam Jon Richardson adamjonr@gmail.comwrote:
On Wed, Feb 27, 2013 at 4:40 PM, Adam Jon Richardson adamjonr@gmail.com
wrote:On Wed, Feb 27, 2013 at 4:30 PM, Nikita Popov nikita.ppv@gmail.com
wrote:On Wed, Feb 27, 2013 at 10:19 PM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:All these are really great arguments for including O+ ... in PHP 5.6.
O+ is
already compatible with PHP 5.5 and as we're just days away from feature
freeze this will stay so til the final release ("stay so" as in
requiring
only minor adjustments). For 5.6 it can then be merged so that we'll be
forced to maintain the opcode cache along the way when doing new engine
changes.Nikita
What will people use as an opcode cache for 5.4?
Adam
Sorry, typo, I meant to say 5.5.
Not sure I understand the question. O+ is compatible with 5.5, so you can
use that if you like. Just install it as an ext. Just like you would have
done with APC.
Nikita
Not sure I understand the question. O+ is compatible with 5.5, so you can
use that if you like. Just install it as an ext. Just like you would have
done with APC.Nikita
More than ANY other language feature, having an integrated opcode
cache (i.e., one that isn't playing catch up but is treated as a core
requirement) would help people adopt PHP 5.5 in a timely manner. APC
was buggy for quite a while after the launch of 5.4 (and know those
who worked on it worked very hard, and I actually took a look at some
of the bugs, but APC seemed to be beyond my skill set.) Knowing that
O+ is compatible with 5.5 doesn't give me confidence that it will work
well. What is the harm in delaying PHP 5.5 and trying to integrate O+
into the release?
Adam
ps: I really love what you guys did with opensourcing it, but I just
think
that it is too late for 5.5 and I think that it is better to stick to the
original roadmap, instead of having a 6 months delay just to ship the O+
in
the core 6months earlier than the next version after 5.5 would be shipped
if we would have followed the yearly release plan in the first place.This is where I think we have a big disconnect. This yearly release plan
is meaningless for most people because there is no way the current
opcode cache situation can keep up with that. PHP 5.4 wasn't really
released until APC was mostly stable with it which was 6+ months after
the release. This is the most urgent thing we need to fix in the PHP
world. Everything else in this 5.5 release is irrelevant as far as I am
concerned and we are pushing because of an arbitrary deadline that is
tighter than most previous releases.In order to actually get the project onto a feasible yearly release
cycle we need to pool the few resources we do have around a single
opcode cache implementation and push it as the one and only option as it
will force each new shiny feature to tackle opcode support from day one
as opposed to circling back around to it as an afterthought as has
happened so often. And no, time has proven that this can't be done by
having it in pecl. It didn't work for APC despite me trying to push that
and I don't see why it would work for O+.Note that if you take the PHP 5.4 release date as the date APC started
working reliably with it, we are well within the yearly release cycle
and not actually late at all.-Rasmus
as Nikita mentioned those who can and willing to upgrade will be able to
use O+ for 5.5 even if it comes in pecl, as it is already in a good shape
for 5.5.
adding it to the core in master will also make sure that there are no
future disconnects between the new features and the opcode cache support.
we discussed this on irc previously so I'm pretty sure that we have to
agree to disagree here, as none of us seeming to change his opinion on the
matter, but I hope we can at least provide some more expressive options for
the vote.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
This is where I think we have a big disconnect. This yearly release plan
is meaningless for most people because there is no way the current
opcode cache situation can keep up with that. PHP 5.4 wasn't really
released until APC was mostly stable with it which was 6+ months after
the release.
That's why having a builtin opcode cache should be a long term goal.
And that's why it will be done this way. All other ways failed.
In order to actually get the project onto a feasible yearly release
cycle we need to pool the few resources we do have around a single
opcode cache implementation and push it as the one and only option as it
will force each new shiny feature to tackle opcode support from day one
Exactly.
Now, about the yearly release, every single person I talked to love it
and want us to keep with this cycle, as well as the more frequent bugs
fixes releases. One thing we have to slightly change is to push too
many new features in each of them, but we will get there.
cheers,
Pierre
@pierrejoye
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Thursday, February 28, 2013 12:17 AM
To: Rasmus Lerdorf
Cc: Ferenc Kovacs; Zeev Suraski; PHP Developers Mailing List
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distributionNow, about the yearly release, every single person I talked to love it
and want us
to keep with this cycle, as well as the more frequent bugs fixes
releases. One
thing we have to slightly change is to push too many new features in
each of
them, but we will get there.
I'm not sure how many people you've spoken to and what their profile is,
but reality shows a very different picture:
481004 PHP/5.2.17
280342 PHP/5.3.8
271156 PHP/5.2.6-1+lenny16
146342 PHP/5.2.9
133818 PHP/5.2.6
125550 PHP/5.3.10
109513 PHP/5.2.6-1+lenny13
106320 PHP/5.2.5
102412 PHP/5.2.14
81221 PHP/5.2.6-1+lenny9
These are the top-10 most popular PHP 5.x versions out there. PHP 5.4.x,
in case you're wondering, shows up on the 44th place, with a bit over 20K
deployments worldwide (5.4.11).
With yearly release cycles, we may make the lives of a few users more
enjoyable and with more rapid access to new features; But for the vast
majority, we're actually making lives worse:
- Framework & app developers can't really rely on new features anyway,
since nobody has those new versions installed. Just two years ago -
aiming for PHP 5.3 seemed like a bold move for ZF2 and Sf2 - and that's
even though PHP 5.3 brought some revolutionary features to the mix (which
5.4 and 5.5 do not). We've also heard the Wordpress way of thinking, and
we can assume that it'd take many years before other apps feel comfortable
requiring a higher version than 5.3.x as a prerequisite. - Users who want to stay secure have to constantly upgrade, since support
lifetimes have been trimmed down substantially (effectively, 3 years from
release; and considering nobody upgrades on to an x.y.0 version, it's
typically way less than that). We can already project that based on the
current frequency, people who install PHP 5.4 today will have less than
two years-worth of lifetime before they're forced to upgrade, or be left
unsupported. - For the ecosystem in general, we're creating lots of fragmentation.
All in all, I think the people who like the yearly release cycle are first
and foremost bleeding edge individual developers, and not people who are a
part of larger projects, or that actually have to worry about production
apps working uninterrupted.
Zeev
Hi,
Am 02/28/2013 11:21 AM, schrieb Zeev Suraski:
I'm not sure how many people you've spoken to and what their profile is,
but reality shows a very different picture:481004 PHP/5.2.17
280342 PHP/5.3.8
you can add another ~100 PHP/5.3.8 installations.
For our company stability and bug fixes are way more important (like
10fold) than having fancy new features. I was asked, if we can switch to
5.4.x but i refused, because it's a couple of days work for each project
to evaluate and migrate to 5.4.x
All in all, I think the people who like the yearly release cycle are first
and foremost bleeding edge individual developers, and not people who are a
part of larger projects, or that actually have to worry about production
apps working uninterrupted.
I personally totally agree.
Cheers, Frank
--
Frank Schenk
Software Analyst
2e Systems
Tel: +49 - 6196 - 95058 - 30
Fax: +49 - 6196 - 95058 - 94
E-mail: frank.schenk@2e-systems.com
Address: 2e Systems GmbH, Königsteiner Str. 87, D-65812 Bad Soden am Taunus
Company registration: Amtsgericht Königstein (Germany), HRB 7303
Director: Philip Douglas
http://www.2e-systems.com/ - making your business fly!
For our company stability and bug fixes are way more important (like
10fold) than having fancy new features. I was asked, if we can switch to
5.4.x but i refused, because it's a couple of days work for each project
to evaluate and migrate to 5.4.x
I can see your point, but don't you think this is also an "old"
mentality that might need to be adjusted? What I mean is that with the
higher frequency of releases, and the more strict "no-BC breaks"
guidelines (many thanks to Pierre and others for doing your best to
enforce that btw..), upgrading becomes less dangerous since there are
less minor changes. I personally can't remember having any issues with
5.4 except for 5.4.0 breaking some odd things in file_get_contents, but
.0 releases are always too buggy to upgrade. I have also been developing
with 5.5 for a while now and did not notice anything out of the ordinary.
Cheers
--
Jordi Boggiano
@seldaek - http://nelm.io/jordi
Jordi Boggiano in php.internals (Thu, 28 Feb 2013 15:33:06 +0100):
For our company stability and bug fixes are way more important (like
10fold) than having fancy new features. I was asked, if we can switch to
5.4.x but i refused, because it's a couple of days work for each project
to evaluate and migrate to 5.4.xI can see your point, but don't you think this is also an "old"
mentality that might need to be adjusted? What I mean is that with the
higher frequency of releases, and the more strict "no-BC breaks"
guidelines (many thanks to Pierre and others for doing your best to
enforce that btw..), upgrading becomes less dangerous since there are
less minor changes. I personally can't remember having any issues with
5.4 except for 5.4.0 breaking some odd things in file_get_contents, but
.0 releases are always too buggy to upgrade. I have also been developing
with 5.5 for a while now and did not notice anything out of the ordinary.
The life cycle of many frameworks is much longer than PHP's release
cycle. Just Google on 'drupal6 views "PHP 5.4"' and you will see that
there are 5.4 issues in one of the core modules in drupal 6. Example:
http://drupal.org/node/1833170
Workaround: turn off strict warnings. You do not want users to do that.
Or, other approach, filter PHP's error messages with regexs:
http://www.howtoeverything.net/linux/drupal/selectively-hide-strict-warning-errors-php-5.4-drupal-6.x-views
Jan
Zeev Suraski wrote:
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Thursday, February 28, 2013 12:17 AM
To: Rasmus Lerdorf
Cc: Ferenc Kovacs; Zeev Suraski; PHP Developers Mailing List
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distributionNow, about the yearly release, every single person I talked to love it
and want us
to keep with this cycle, as well as the more frequent bugs fixes
releases. One
thing we have to slightly change is to push too many new features in
each of
them, but we will get there.
I'm not sure how many people you've spoken to and what their profile is,
but reality shows a very different picture:481004 PHP/5.2.17
280342 PHP/5.3.8
271156 PHP/5.2.6-1+lenny16
146342 PHP/5.2.9
133818 PHP/5.2.6
125550 PHP/5.3.10
109513 PHP/5.2.6-1+lenny13
106320 PHP/5.2.5
102412 PHP/5.2.14
81221 PHP/5.2.6-1+lenny9These are the top-10 most popular PHP 5.x versions out there. PHP 5.4.x,
in case you're wondering, shows up on the 44th place, with a bit over 20K
deployments worldwide (5.4.11).
With yearly release cycles, we may make the lives of a few users more
enjoyable and with more rapid access to new features; But for the vast
majority, we're actually making lives worse:
- Framework & app developers can't really rely on new features anyway,
since nobody has those new versions installed. Just two years ago -
aiming for PHP 5.3 seemed like a bold move for ZF2 and Sf2 - and that's
even though PHP 5.3 brought some revolutionary features to the mix (which
5.4 and 5.5 do not). We've also heard the Wordpress way of thinking, and
we can assume that it'd take many years before other apps feel comfortable
requiring a higher version than 5.3.x as a prerequisite.- Users who want to stay secure have to constantly upgrade, since support
lifetimes have been trimmed down substantially (effectively, 3 years from
release; and considering nobody upgrades on to an x.y.0 version, it's
typically way less than that). We can already project that based on the
current frequency, people who install PHP 5.4 today will have less than
two years-worth of lifetime before they're forced to upgrade, or be left
unsupported.- For the ecosystem in general, we're creating lots of fragmentation.
All in all, I think the people who like the yearly release cycle are first
and foremost bleeding edge individual developers, and not people who are a
part of larger projects, or that actually have to worry about production
apps working uninterrupted.
Finally some agreement with what I've been getting my head chewed off every time
I bring it up! For the last couple of years ...
--
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
I'm not sure how many people you've spoken to and what their profile is,
but reality shows a very different picture:481004 PHP/5.2.17
280342 PHP/5.3.8
271156 PHP/5.2.6-1+lenny16
146342 PHP/5.2.9
133818 PHP/5.2.6
125550 PHP/5.3.10
109513 PHP/5.2.6-1+lenny13
106320 PHP/5.2.5
102412 PHP/5.2.14
81221 PHP/5.2.6-1+lenny9
These are the top-10 most popular PHP 5.x versions out there. PHP 5.4.x,
in case you're wondering, shows up on the 44th place, with a bit over 20K
deployments worldwide (5.4.11).
With yearly release cycles, we may make the lives of a few users more
enjoyable and with more rapid access to new features; But for the vast
majority, we're actually making lives worse:
This is amazing how you take every single opportunity to bash the new
release process, forgetting all pro arguments that have been brought
in the last discussions.
Let me write them down again in (hopefully) a more understandable way:
-
smaller and more frequent releases are easier to manage, from a
core dev, QA, ISPs and applications/developers point of view. Those
are our targets, not pepsi drinkers (read: consumers, they don't even
care if php runs under the hood as long as the app runs) -
100% BC compatibility between x.y and x.y+1. This is what prevents
many ISPs and other mass hosting to update to newer PHP versions. They
don't test if it works or not, they simply don't update due (too
expensive in support and revert) to our past bad job on keeping BC. -
Judging the result of this process when only one release so far has
been published is totally wrong.
Instead of fighting it, what's about Zend talking about it to its so
numerous customers? For a change.
- Framework & app developers can't really rely on new features anyway,
since nobody has those new versions installed. Just two years ago -
aiming for PHP 5.3 seemed like a bold move for ZF2 and Sf2 - and that's
even though PHP 5.3 brought some revolutionary features to the mix (which
5.4 and 5.5 do not). We've also heard the Wordpress way of thinking, and
we can assume that it'd take many years before other apps feel comfortable
requiring a higher version than 5.3.x as a prerequisite.
I have discussed with many WP devs (and the lead), they all agree that
this process is a good thing and will help WP to move forward. It does
not mean they will stop to support older versions but they will change
the recommended versions.
- Users who want to stay secure have to constantly upgrade, since support
lifetimes have been trimmed down substantially (effectively, 3 years from
release; and considering nobody upgrades on to an x.y.0 version, it's
typically way less than that). We can already project that based on the
current frequency, people who install PHP 5.4 today will have less than
two years-worth of lifetime before they're forced to upgrade, or be left
unsupported.
Again, 1st release done via through this process. Our users (not the
consumers of our users products) have to see that we keep our word,
about BC, quality etc.
- For the ecosystem in general, we're creating lots of fragmentation.
No, we do not. 5.4 code runs under 5.5 smoothly. But we do not prevent
newer versions of applications or modules to rely on 5.5 features. I
am convinced that the update path will be faster in the next couple of
years. The only missing part now is the communication about it. I have
been communicating about it at all conferences I attended as speaker
(talks, keynotes, etc.). I did not see any single negative comments
about it, but only positive and very motivated feedback. While people
also said that they will wait to see if we keep our words (as I said
earlier).
All in all, I think the people who like the yearly release cycle are first
and foremost bleeding edge individual developers, and not people who are a
part of larger projects, or that actually have to worry about production
apps working uninterrupted.
Having the pros of both sides is exactly why this process has been
created. Having a release active for almost a decade is simply not
possible.
Let me say it again, stop arguing and begin to promote and explain it
to your customers. That will be much more helpful than trying to fight
it with all possible ways.
Thanks.
Cheers,
Pierre
@pierrejoye
This is amazing how you take every single opportunity to bash the new
release
process, forgetting all pro arguments that have been brought in the last
discussions.
I'm not bashing it. I think the process is good. I'm saying the
frequency is wrong and doesn't suit the needs of most of our users.
Let me write them down again in (hopefully) a more understandable way:
You didn't state anything I wasn't aware of before, and yet, I still think
that a yearly release cycle is roughly 2x too frequent from where we
should be.
Most users don't upgrade because they don't need the new features and
can't be bothered to upgrade.
There's no such thing as 100% downwards compatibility, and 5.5 will be no
different in that sense from previous versions. Perhaps it'll be three
nines instead of two nines (99.9% vs. 99%), but every keyword, every bug
fix, every change in an error reporting level - can break apps and make an
upgrade process non smooth. We're not going to be able to change people's
perception.
Frequent releases are less easy to manage from just about any point.
Their one and only advantage is delivering features to the userbase more
quickly, which begs the question whether they're eagerly waiting for such
features.
In terms of upgrades - you have to spend more time upgrading & testing.
In terms of off-the-shelf-apps - you need to invest more in testing more
versions. In terms of QA - fewer releases means less time spent in
testing.
Instead of fighting it, what's about Zend talking about it to its so
numerous
customers? For a change.
Zend has nothing to do with it. We can't wave a magic wand and change
people's perception, habits or preferences. Both our customers and the
companies I get to meet don't view a yearly release cycle favorably (most
of them - some do).
I have discussed with many WP devs (and the lead), they all agree that
this
process is a good thing and will help WP to move forward. It does not
mean they
will stop to support older versions but they will change the recommended
versions.
Process != frequency. Our process is good, our frequency isn't.
No, we do not. 5.4 code runs under 5.5 smoothly.
5.3 code runs smoothly on 5.4 too (except for ancient code using features
that have been deprecated for many many years). Incompats have been blown
out of proportion - in the same way I can assure you the few incompats
between 5.4 and 5.5 will be blown out of proportion.
Let me say it again, stop arguing and begin to promote and explain it to
your
customers.
I admire your self-confidence, you seem to have enough of it for a whole
battalion of developers, but it's complete unwarranted in this case (as
well as other cases in recent weeks). I think you're promoting a bad
thing for PHP, not because our users are idiots or fail to understand the
amazing advantages of a yearly release cycle - but because it's just bad.
Zeev
hi Zeev,
Most users don't upgrade because they don't need the new features and
can't be bothered to upgrade.There's no such thing as 100% downwards compatibility, and 5.5 will be no
different in that sense from previous versions. Perhaps it'll be three
nines instead of two nines (99.9% vs. 99%), but every keyword, every bug
fix, every change in an error reporting level - can break apps and make an
upgrade process non smooth. We're not going to be able to change people's
perception.
nitpicking. You know what I mean.
I admire your self-confidence, you seem to have enough of it for a whole
battalion of developers, but it's complete unwarranted in this case
I have to suggest to join me in the next conferences then. Like the
one I gave talks about this topic (DrupalCons, general PHP
conferences, dozen of UGs, companies conferences, etc.). And the
attendees are not the usual suspects you could find at some major US
conferences.
(as well as other cases in recent weeks).
I suppose you refer to my comments about us being out of sync with our
user bases, let say you talk to part of our users and I do to another.
Amazingly most of the frameworks and apps lead developers think the
same have the same opinion, go figure.
I think you're promoting a bad
thing for PHP, not because our users are idiots or fail to understand the
amazing advantages of a yearly release cycle - but because it's just bad.
I promote what I and the users I talk to believe to be a good thing.
Cheers,
Pierre
@pierrejoye
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Thursday, February 28, 2013 3:12 PM
To: Zeev Suraski
Cc: Ferenc Kovacs; Rasmus Lerdorf; PHP Developers Mailing List
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distributionhi Zeev,
Most users don't upgrade because they don't need the new features and
can't be bothered to upgrade.There's no such thing as 100% downwards compatibility, and 5.5 will be
no different in that sense from previous versions. Perhaps it'll be
three nines instead of two nines (99.9% vs. 99%), but every keyword,
every bug fix, every change in an error reporting level - can break
apps and make an upgrade process non smooth. We're not going to be
able to change people's perception.nitpicking. You know what I mean.
Of course I do, but I would say that saying 5.4 is 'extremely incompatible
with 5.3' is also nitpicking. Which is why I doubt 5.5 will see
dramatically different adoption rates from 5.4. If anything, having O+
inside 5.5 would help - although personally I think that the reason people
aren't upgrading to 5.4 isn't just the fact APC wasn't available. It's
simply not a priority for them as earlier versions are already doing
everything they need, and if it ain't broke - don't fix it.
I have to suggest to join me in the next conferences then. Like the one
I gave
talks about this topic (DrupalCons, general PHP conferences, dozen of
UGs,
companies conferences, etc.). And the attendees are not the usual
suspects you
could find at some major US conferences.
The conferences you cite are very, very developer centric. As weird as it
may sound - developers typically don't get to choose what version of PHP
they run on, beyond perhaps the initial setup. Operations people do. And
they won't install PHP 5.5 because Pierre tells them it's 100% compatible.
They'd need to (a) have a good reason to upgrade (b) have it prioritized
high enough over all the other things they need to do (c) have apps fully
tested before they roll a version out. I, for one, wouldn't dream of
rolling out PHP 5.5 without fully testing that nothing broke, and I'm not
exactly a very conservative ops person.
I suppose you refer to my comments about us being out of sync with our
user
bases, let say you talk to part of our users and I do to another.
I refer to your lack of respect for pluralism, the fact that other people
may have a different opinion, and that possibility that you may simply not
be right. Just in case it wasn't clear - I very much admit the
possibility that I may be wrong, and that the yearly cycle is a good
thing. Everything I know about how PHP is actually being used in
production tells me otherwise, but you're not going to hear something
along the lines of "it's not my opinion but a simple fact", even if though
I very strongly believe in what I say.
Amazingly most of the frameworks and apps lead developers think the same
have the same opinion, go figure.
If 5.3 was any indication, then the leaders of the two biggest frameworks
barely made the decision to switch to PHP 5.3 almost a full year after it
came out, and that's just as they were gearing up to start developing.
Drupal 8, that just came out - doesn't take advantage of PHP 5.4 features,
and only discontinued support for PHP 5.2. WP still supports 5.2, and
therefore doesn't even take advantage of PHP 5.3 features. The list goes
on.
Could it be that you're just a tad bit too self-confident with the yearly
release cycle? I know you'd say 'no', the question is directed to others
reading this message.
Zeev
Zeev Suraski wrote:
Of course I do, but I would say that saying 5.4 is 'extremely incompatible
with 5.3' is also nitpicking. Which is why I doubt 5.5 will see
dramatically different adoption rates from 5.4. If anything, having O+
inside 5.5 would help - although personally I think that the reason people
aren't upgrading to 5.4 isn't just the fact APC wasn't available. It's
simply not a priority for them as earlier versions are already doing
everything they need, and if it ain't broke - don't fix it.
Code which originated in pre 5.3 days and has had the faults hidden when running
on 5.3 still needs work to run on 5.4. If the faults were fixed in 5.3, then
it's more likely to run on 5.4 even with e_strict off. I have yet to get a
legacy site that does not need a few hours work to get it running again in 5.4.
I've still another 60 odd to work through and some of them still use things
removed in 5.4. The hassle with <?= stopping working is a good example of the
sort of thing which affects confidence in upgrading!
The reality is that one simply can't switch existing code between versions of
PHP without first checking it, and checking every site take time. We are having
to test on 5.3 because that is what ISP's are moving to, while it would be nice
simply to skip that step and go straight to 5.4. Having moved to 5.3 then it
still leaves a question - do you switch on the hidden stuff and see if it can be
tidied up? It's finding the time to clean up all of the hidden warnings that is
the killer :(
Finding time to test everything again in 5.5 is simply not going to happen this
end, and I'm more than happy with eaccelerator in production. Everything is
running stability so why should I be wasting all this time anyway? The paying
customers simply expect their sites to work ...
--
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
Zeev has an excellent point here, my own research shows that 5.4, a
year after release had somewhere in the 2% adoption rate. The major
reason being is the lack of a stable, production ready op-code cache.
To release 5.5 without a good solution for that problem, would not
make the situation better, if anything it would make it very
intimidating to users to jump 2-3 versions directly to 5.6. Thus
leaving us with a massive user base running legacy, unsupported
versions containing unresolved bugs and vulnerabilities. Something,
which I don't think would be a very good thing for the future of PHP.
Ultimately, I think it is better to wait a month or two (if that is
what it takes) and have a solid release people can safely upgrade
their production environments to, rather than strictly adhere to a set
release cycle and delivery a partial solution.
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Thursday, February 28, 2013 12:17 AM
To: Rasmus Lerdorf
Cc: Ferenc Kovacs; Zeev Suraski; PHP Developers Mailing List
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distributionNow, about the yearly release, every single person I talked to love it
and want us
to keep with this cycle, as well as the more frequent bugs fixes
releases. One
thing we have to slightly change is to push too many new features in
each of
them, but we will get there.I'm not sure how many people you've spoken to and what their profile is,
but reality shows a very different picture:481004 PHP/5.2.17
280342 PHP/5.3.8
271156 PHP/5.2.6-1+lenny16
146342 PHP/5.2.9
133818 PHP/5.2.6
125550 PHP/5.3.10
109513 PHP/5.2.6-1+lenny13
106320 PHP/5.2.5
102412 PHP/5.2.14
81221 PHP/5.2.6-1+lenny9These are the top-10 most popular PHP 5.x versions out there. PHP 5.4.x,
in case you're wondering, shows up on the 44th place, with a bit over 20K
deployments worldwide (5.4.11).
With yearly release cycles, we may make the lives of a few users more
enjoyable and with more rapid access to new features; But for the vast
majority, we're actually making lives worse:
- Framework & app developers can't really rely on new features anyway,
since nobody has those new versions installed. Just two years ago -
aiming for PHP 5.3 seemed like a bold move for ZF2 and Sf2 - and that's
even though PHP 5.3 brought some revolutionary features to the mix (which
5.4 and 5.5 do not). We've also heard the Wordpress way of thinking, and
we can assume that it'd take many years before other apps feel comfortable
requiring a higher version than 5.3.x as a prerequisite.- Users who want to stay secure have to constantly upgrade, since support
lifetimes have been trimmed down substantially (effectively, 3 years from
release; and considering nobody upgrades on to an x.y.0 version, it's
typically way less than that). We can already project that based on the
current frequency, people who install PHP 5.4 today will have less than
two years-worth of lifetime before they're forced to upgrade, or be left
unsupported.- For the ecosystem in general, we're creating lots of fragmentation.
All in all, I think the people who like the yearly release cycle are first
and foremost bleeding edge individual developers, and not people who are a
part of larger projects, or that actually have to worry about production
apps working uninterrupted.Zeev
Ilia,
Zeev has an excellent point here, my own research shows that 5.4, a
year after release had somewhere in the 2% adoption rate. The major
reason being is the lack of a stable, production ready op-code cache.
To release 5.5 without a good solution for that problem, would not
make the situation better, if anything it would make it very
intimidating to users to jump 2-3 versions directly to 5.6. Thus
leaving us with a massive user base running legacy, unsupported
versions containing unresolved bugs and vulnerabilities. Something,
which I don't think would be a very good thing for the future of PHP.
To be fair, the 5.5 situation without pulling in ZO+ is NOT the same as 5.4
was. Today, right now, there exists at least one stable open source opcode
cache. 5.4 had none for many months after release. So I'm not sure if the
same pressures exist.
The discussion now is if we delay 5.5 to spend the time pulling it in core.
But either way (in core or not), ZO+ is open and working on 5.5 alpha. So
we could skip the core import, and just ship it today as gold, and it would
be adoptable straight away (unlike how 5.4 was).
Ultimately, I think it is better to wait a month or two (if that is
what it takes) and have a solid release people can safely upgrade
their production environments to, rather than strictly adhere to a set
release cycle and delivery a partial solution.
That's the thing though, it wouldn't be a partial solution. It would be
exactly where 5.2, 5.3 and 5.4 are today, with the addition of several
highly wanted features.
I'd rather delay 5.6, and do a deeper integration into the engine. Then at
least there's something to gain by pulling it into core, rather than just
having it be a compile-time-flag as opposed to a pecl installation (which
doesn't buy us that much)...
My standpoint at least...
Anthony
To be fair, the 5.5 situation without pulling in ZO+ is NOT the same as 5.4
was. Today, right now, there exists at least one stable open source opcode
cache. 5.4 had none for many months after release. So I'm not sure if the
same pressures exist.
If you are referring to APC as the stable cache, that unfortunately is
not entirely correct, it is still relatively easy to crash APC unless
some work-arounds are applied. I was speaking to a several people at
the conference just yesterday and they were indicating frequent
crashes with APC, the work-arounds appear to have solved their issues,
but those are not exactly obvious.
The discussion now is if we delay 5.5 to spend the time pulling it in core.
But either way (in core or not), ZO+ is open and working on 5.5 alpha. So we
could skip the core import, and just ship it today as gold, and it would be
adoptable straight away (unlike how 5.4 was).
Well the question around the delay, is what is the negative
consequence of the delay, versus the advantage of having a built-in
opcode cache shipped as part of 5.5 which is likely to give many
people an impetuous to upgrade from their current 5.2/5.3 install.
Well the question around the delay, is what is the negative
consequence of the delay, versus the advantage of having a built-in
opcode cache shipped as part of 5.5 which is likely to give many
people an impetuous to upgrade from their current 5.2/5.3 install.
If we get to get it stable in a relatively short period. It is hard with
APC, which is available open since its very 1st day, it is harder with o+,
new code, new algos, new settings, etc.
Pierre
Well the question around the delay, is what is the negative
consequence of the delay, versus the advantage of having a built-in
opcode cache shipped as part of 5.5 which is likely to give many
people an impetuous to upgrade from their current 5.2/5.3 install.If we get to get it stable in a relatively short period. It is hard with
APC, which is available open since its very 1st day, it is harder with o+,
new code, new algos, new settings, etc.
If ZO+ was a brand new code, I'd agree with you 100%. However, it is
an existing solution that has been used in a wild in quite some time
an limited empirical evidence shows that it works somewhat better than
APC in most cases from stability perspective.
Ultimately, peoples opinions will drive the decision, just wanted to
share my perspective based on personal experience and feedback that I
got from people trying to use 5.4 in production and their expressed
pains...
If ZO+ was a brand new code, I'd agree with you 100%. However, it is
an existing solution that has been used in a wild in quite some time
an limited empirical evidence shows that it works somewhat better than
APC in most cases from stability perspective.
It is not the version provided before. Things have been removed, changed,
etc.
We both know that it is not an easy thing to do with an opcode cache.
Ilia,
If you are referring to APC as the stable cache, that unfortunately is
not entirely correct, it is still relatively easy to crash APC unless
some work-arounds are applied. I was speaking to a several people at
the conference just yesterday and they were indicating frequent
crashes with APC, the work-arounds appear to have solved their issues,
but those are not exactly obvious.
Even more evidence that the situation for 5.5 is not the same as for 5.4,
as a stable cache does exist for 5.5, when it still doesn't for 5.4...
But either way:
The discussion now is if we delay 5.5 to spend the time pulling it in
core.
But either way (in core or not), ZO+ is open and working on 5.5 alpha.
So we
could skip the core import, and just ship it today as gold, and it would
be
adoptable straight away (unlike how 5.4 was).Well the question around the delay, is what is the negative
consequence of the delay, versus the advantage of having a built-in
opcode cache shipped as part of 5.5 which is likely to give many
people an impetuous to upgrade from their current 5.2/5.3 install.
What advantage do we get by doing a surface level inclusion? We're not
going to refactor the engine for 5.5. We're not going to do any deep
integrations in 5.5 (or as the RFC puts it, "soft integrations"). So what
is the advantage of inclusion?
From my eyes, the only advantage for a soft integration is the fact that
the source code is bundled. It wouldn't be enabled by default (which is
VERY ambiguous from the RFC). It wouldn't provide ANY benefit from it being
in PECL with the exception that the source code ships together with core...
What is the disadvantage to bringing it in 5.5? Well, there are a few:
-
We're holding up the 5.5 release indefinitely. Meaning that we're not
time-boxed as the RFC process intends the release to be, but instead we're
feature boxed. What happens if we approve this for 5.5, and in two weeks
everyone working on it decides to go on vacation for two years. We're stuck
in the same boat as we are with 6. We promised and agreed to do something,
but for whatever reason didn't. That's EXACTLY what this time-boxed RFC
process does. It prevents that from happening. -
We've already delayed 5.5 by a month. When Zeev first offered to open
source it, the message presented then was that it would be out in a few
days (end of week I think was the original message), and it would only take
a few days from there to integrate. Now we're a month later, and the source
was just made available 1 week ago. Two weeks later than promised. And it's
looking like an additional several months of work to integrate. I'm deeply
concerned that "oh it should only take 2 months to fix up" could very
easily turn into a LOT longer of a time... Which would be bad for everyone. -
It's sending the wrong message. We have policies and procedures for a
reason. Now, I have no issue with having a deviation policy that allows us
to deviate, but let's be smart about the deviations. Doing a deviation here
basically says the whole release process is bad, and we can do whatever we
want whenever we want as long as it's popular. That's not why we agree on
policies and procedures...
My thoughts at least...
Anthony
If you are referring to APC as the stable cache, that unfortunately is
not entirely correct, it is still relatively easy to crash APC unless
some work-arounds are applied. I was speaking to a several people at
the conference just yesterday and they were indicating frequent
crashes with APC, the work-arounds appear to have solved their issues,
but those are not exactly obvious.Even more evidence that the situation for 5.5 is not the same as for 5.4, as
a stable cache does exist for 5.5, when it still doesn't for 5.4...
Wouldn't that make it ever so important to address this issue before
releasing another version, since production use of PHP pretty much
requires use of an opcode cache if you want any degree of performance?
Hi!
If you are referring to APC as the stable cache, that unfortunately is
not entirely correct, it is still relatively easy to crash APC unless
some work-arounds are applied. I was speaking to a several people at
the conference just yesterday and they were indicating frequent
crashes with APC, the work-arounds appear to have solved their issues,
but those are not exactly obvious.
Do we have those ways and work-arounds recorded somewhere? It would be a
very good idea to have tests for O+ to ensure there are no problems in
these areas (or if there are, to fix them :). My experience suggests
opcode cache solutions often tend to have issues in the same areas, so I
think it'd be very useful.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
The APC issues are somewhat APC specific in most cases, they often
revolve around memory utilization issues and garbage collection. Some
of the work-arounds involve ensuring APC always has extra memory to
prevent fragmentation. When fragmentation goes about 35-40% clearing
out the entire cache to prevent increase in fragmentation which in
many cases can reduce stability.
Loading large number of files in parallel is another thing that
frequently can negatively impact APC, doing pre-loading or staggering
the loading process is the work-around that typically prevents issues.
Hi!
If you are referring to APC as the stable cache, that unfortunately is
not entirely correct, it is still relatively easy to crash APC unless
some work-arounds are applied. I was speaking to a several people at
the conference just yesterday and they were indicating frequent
crashes with APC, the work-arounds appear to have solved their issues,
but those are not exactly obvious.Do we have those ways and work-arounds recorded somewhere? It would be a
very good idea to have tests for O+ to ensure there are no problems in
these areas (or if there are, to fix them :). My experience suggests
opcode cache solutions often tend to have issues in the same areas, so I
think it'd be very useful.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi Ilia,
Zeev has an excellent point here, my own research shows that 5.4, a
year after release had somewhere in the 2% adoption rate. The major
reason being is the lack of a stable, production ready op-code cache.
To release 5.5 without a good solution for that problem, would not
make the situation better, if anything it would make it very
intimidating to users to jump 2-3 versions directly to 5.6. Thus
leaving us with a massive user base running legacy, unsupported
versions containing unresolved bugs and vulnerabilities. Something,
which I don't think would be a very good thing for the future of PHP.
I do not oppose to have O+ in core. I am only opposed to have it right
now in 5.5 given the current state of its development, stability and
lack of pecl releases.
Ultimately, I think it is better to wait a month or two (if that is
what it takes) and have a solid release people can safely upgrade
their production environments to, rather than strictly adhere to a set
release cycle and delivery a partial solution.
All distributions will provide it as a separate package anyway. For
most of our users there will be zero difference if it is core with 5.5
or in pecl only (or both). As Anthony said earlier, doing our best to
get 5.5 out sooner rather than later and move to the next step for o+,
the actual integration (no, I do not refer to cleanup legacy code in
o+ but tight integration to the engine). That will actually bring a
lot more benefits to our users.
Cheers,
Pierre
@pierrejoye
The major reason being is the lack of a stable, production ready op-code cache.
Am I crazy or APC not stable != a lack of a stable opcode cache. Whole
discussion thread has been assuming people don't use anything and or
there's nothing better than both ZO and APC - both facts being
patently untrue. I hate to get adversarial about this stuff, but PHP
seems to be suffering with a serious case of Not Invented Here syndrome
at the moment.
Real world ZO isn't going to make people switch to PHP 5.5 and nothing
but distro movement on this issue (around their release process) and
good time are going to change that. It's always applied with PHP (and
many other languages and projects) and it always will. Linux kernel is
at 3.8.1 but Debian testing is shipping 3.2, because that's what the
release process demands. Most sane people are going to use the PHP
version their distro ships and most distros are going to ship what is
tested, and not for nothing but bundling ZO if anything is going to gum
up the works on that front because simply it's more code and features
that will need testing and more config options to find sane defaults for.
TL;DR - ZO isn't going to shift people.
Am 27.2.2013 um 22:01 schrieb Ferenc Kovacs tyra3l@gmail.com:
I'm not sure that the current options covering all cases.
How should one vote if he/she thinks that this should go into the next
release after 5.5?
Currently their only option would be to vote for no, which isn't doesn't
really the same thing.
Personally I would prefer roll out 5.5 without O+, but release it in PECL
for all supported branches and move it for core in master(which means
having it in 5.6/6.0/whatever will be the next version).
Currently I don't have an option which I'm comfortable with, maybe there
are others in the similar situation.ps: I really love what you guys did with opensourcing it, but I just think
that it is too late for 5.5 and I think that it is better to stick to the
original roadmap, instead of having a 6 months delay just to ship the O+ in
the core 6months earlier than the next version after 5.5 would be shipped
if we would have followed the yearly release plan in the first place.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I don't see any reason why we should even have the idea to integrate O+
when it's possible to do it without any delay. Where is the big advantage
of letting customers waiting longer than needed? (Yes, they can install it
from PECL, but this is a suboptimal solution as it is no reason why
installing PHP 5.5)
A major release has to have a sense. There are generators... A finally
keyword... list in foreach...!??? Shiny new features is the right name for
this. Nothing you need. It may clean up code to use them, but this is not
important enough to update, deal with the deprecated mysql extension,
test the environment if everything works with it. Also a lot of users have
PHP versions older than PHP5.4. Some of them may still relay on removed
features like these magic_quotes etc. They all have to change their code
for an update. If there is nothing really important like a faster opcode cache
(faster than APC), less crashes under high load (we have sometimes these
unreproducible reports in the bug list...), they don't matter about it.
Please name me a few good reasons what sense releasing a PHP version
nobody (who is not a developer) cares about it makes.
Bob
(p.s.: I like also these shiny features, but if they'd be so important, you could
also install from trunk. (That's what I do.) And don't tell me the myth that only
releases can be stable. Only a few weeks after the introduction of a new
feature it is often as stable as in the future major version.)
Based on the overwhelming response, the vote is now open J
https://wiki.php.net/rfc/optimizerplus
Voting ends March 7th.
ok, given the total lack of answers, mistakes and misleading wording
in the RFC and lack of releases in PECL (which is a pre requise since
quite some time to get in core), I'd to vote -1 for now.
It will surely won't change anything but I stand to what we discuss.
--
Pierre
@pierrejoye
Den 28/02/2013 kl. 07.53 skrev Pierre Joye pierre.php@gmail.com:
ok, given the total lack of answers, mistakes and misleading wording
in the RFC and lack of releases in PECL (which is a pre requise since
quite some time to get in core), I'd to vote -1 for now.
My reasons exactly for now, while it is tempting to vote against our own agreements
-K
Based on the overwhelming response, the vote is now open J
https://wiki.php.net/rfc/optimizerplus
Voting ends March 7th.
ok, given the total lack of answers, mistakes and misleading wording
in the RFC and lack of releases in PECL (which is a pre requise since
quite some time to get in core), I'd to vote -1 for now.
+1,
there should be a option "release at PECL", which will give the O+
more feedback and test
thanks
It will surely won't change anything but I stand to what we discuss.
--
Pierre@pierrejoye
--
--
Laruence Xinchen Hui
http://www.laruence.com/
ok, given the total lack of answers, mistakes and misleading wording
in the RFC and lack of releases in PECL (which is a pre requise since
quite some time to get in core), I'd to vote -1 for now.
+1,
there should be a option "release at PECL", which will give the O+
more feedback and test
There is one, its the third option.
Zeev
hi Zeev,
ok, given the total lack of answers, mistakes and misleading wording
in the RFC and lack of releases in PECL (which is a pre requise since
quite some time to get in core), I'd to vote -1 for now.
+1,
there should be a option "release at PECL", which will give the O+
more feedback and testThere is one, its the third option.
Ok this is getting ridiculous.
How "Don’t integrate Optimizer+ to PHP" can be remotely related to the
available of o+ via PECL?
No matter the results, having o+ available in PECL for < 5.5 is a very
good thing and many are expecting as well. Not doing it means that
only 5.5 is supported and that defeats the whole purpose of having one
opcode cache to rule them all. Why? Because we will still have to use
most of our resources to support APC and wincache for 5.3 and 5.4.
At some point I think I will simply do it myself and be done with this
sterile discussion, it is OSS anyway and the license allows anyone to
do it.
Cheers,
Pierre
@pierrejoye
How "Don't integrate Optimizer+ to PHP" can be remotely related to the
available of o+ via PECL?
Actually it seems as if some of the original text got lost when I switched
to the active vote, but it used to read 'Don't integrate Optimizer+ to
PHP, release only in PECL'. My bad.
Zeev
How "Don't integrate Optimizer+ to PHP" can be remotely related to the
available of o+ via PECL?Actually it seems as if some of the original text got lost when I switched
to the active vote, but it used to read 'Don't integrate Optimizer+ to
PHP, release only in PECL'. My bad.
No offense and pls do not see what I will say here as an attempt to
block it, as I really want o+ in core.
I think this RFC should be fixed (fix wording to represent the actual
actions, s,integration,bundling&cleanup,), votes options added to
cover what has been discussed. Add a roadmap as well for the further
steps that can/could/will be taken to make o+ even better while being
in core.
The options should include PECL, either it is in core or not. So you
can get an idea about how many people wants < 5.5 support and releases
as well.
Cheers,
Pierre
@pierrejoye
How "Don't integrate Optimizer+ to PHP" can be remotely related to the
available of o+ via PECL?Actually it seems as if some of the original text got lost when I switched
to the active vote, but it used to read 'Don't integrate Optimizer+ to
PHP, release only in PECL'. My bad.No offense and pls do not see what I will say here as an attempt to
block it, as I really want o+ in core.I think this RFC should be fixed (fix wording to represent the actual
actions, s,integration,bundling&cleanup,), votes options added to
cover what has been discussed. Add a roadmap as well for the further
steps that can/could/will be taken to make o+ even better while being
in core.The options should include PECL, either it is in core or not. So you
can get an idea about how many people wants < 5.5 support and releases
as well.
The RFC is about integrating O+ into PHP which can by definition only
happen in 5.5 and later. The essential questions being asked by the RFC
are whether to delay 5.5 for it, no delay and wait until the next
version, or don't integrate at all the last of which implies
external-only distribution either through pecl or individual distros
simply packaging it from Github.
And your beef about integration vs. bundling is rather nit-picky. The
first step towards integration is getting it in. How much integration is
done will depend on what people come up with. I have a pull request in
for at least one level of integration that will allow it to save a stat
call by integrating more closely with the sapi layer to save that
initial stat if the sapi layer can pull it from the server layer. That
is more than mere bundling, but it should also be rather safe to do.
What we do about earlier versions is a completely separate and mostly
unrelated issue. There is no real reason not to support those via pecl,
but that isn't what this RFC is about. And, like you say, there is
nothing stopping you or anybody else from making a pointer to it from pecl.
-Rasmus
The RFC is about integrating O+ into PHP which can by definition only
happen in 5.5 and later.
Implicitly no, while it is clear that it has to be done. But
explicitly the RFC uses the word integration for 5.5 and it won't
happen. However what is voted on is:
"Integrate into 5.5, even if minor delay required"
"Integrate into 5.5 only if it's not delayed, otherwise - 5.6"
"Don’t integrate Optimizer+ to PHP"
And what will actually happen if accepted is bundling&cleanup for 5.5,
integration in 5.6 or later.
That makes a rather huge difference, especially when it is about
delaying 5.5 for a relatively unknown period. It is even more
disturbing as the gain between that and having it in PECL for the
meantime is very very low.
A real integration (at least partially) may be done it during the beta
phases but I very much doubt that it is feasible, stabilize it will
likely take more time and beginning to do many changing to actually
integrate o+ into core is way too risky during beta/RC phases.
The essential questions being asked by the RFC
are whether to delay 5.5 for it, no delay and wait until the next
version, or don't integrate at all the last of which implies
external-only distribution either through pecl or individual distros
simply packaging it from Github.
Distros will distribute it as separate packages anyway, I do not
really the point here.
And your beef about integration vs. bundling is rather nit-picky.
No, it is not. Hence why I asked to have the roadmap (no date but a
plan and actual actions listed) to have an informed vote.
The
first step towards integration is getting it in.
That does not guarantee that further steps can be done, from a timely manner.
How much integration is
done will depend on what people come up with. I have a pull request in
for at least one level of integration that will allow it to save a stat
call by integrating more closely with the sapi layer to save that
initial stat if the sapi layer can pull it from the server layer.That
is more than mere bundling, but it should also be rather safe to do.
That is done in APC already. Any extensions can use it, being in core or not.
What we do about earlier versions is a completely separate and mostly
unrelated issue. There is no real reason not to support those via pecl,
but that isn't what this RFC is about. And, like you say, there is
nothing stopping you or anybody else from making a pointer to it from pecl.
I agree, it is a separate issue. However it does affect the decision
about delaying 5.5 for it while everything do or add can be done via
pecl. That's why I think everything should be part of the RFC so
voters can take an informed decision based on the actual planed moves.
The question about little 5.4 adoption because of the lack of opcode
cache support does not apply to 5.5 and o+ as it already supports
quite well, minus the remaining issues (see Matt's post earlier this
week).
But again, I am not trying to stop o+ being in core, but the contrary.
Almost all our (my team colleagues) resources are on testing 5.5 and
o+ (and APC too as a fallback). We also provided patches, use cases,
etc. we discovered or implemented while testing 5.3/4/5 and o+ with
our tests benchmarks. My only point is the actual gain to delay 5.5
even more without knowing when we can release it, shooting in the dark
and the lack of PECL support for previous php versions (as in: won't
reduce our work load because we will still have to support APC as a
prio #1 for 5.3/4).
Cheers,
Pierre
@pierrejoye
The
first step towards integration is getting it in.That does not guarantee that further steps can be done, from a timely manner.
There is never any such guarantee and the current results of the vote
clearly says that the majority of people are fine with a delayed 5.5
release.
How much integration is
done will depend on what people come up with. I have a pull request in
for at least one level of integration that will allow it to save a stat
call by integrating more closely with the sapi layer to save that
initial stat if the sapi layer can pull it from the server layer.That
is more than mere bundling, but it should also be rather safe to do.That is done in APC already. Any extensions can use it, being in core or not.
So? It is not done in O+. The fact that APC is better integrated on this
particular point doesn't invalidate this as a low-hanging fruit
integration step for O+. And there are other such low-hanging fruits we
are likely to find, test and deem stable enough to get into 5.5.
What we do about earlier versions is a completely separate and mostly
unrelated issue. There is no real reason not to support those via pecl,
but that isn't what this RFC is about. And, like you say, there is
nothing stopping you or anybody else from making a pointer to it from pecl.I agree, it is a separate issue. However it does affect the decision
about delaying 5.5 for it while everything do or add can be done via
pecl. That's why I think everything should be part of the RFC so
voters can take an informed decision based on the actual planed moves.
The question about little 5.4 adoption because of the lack of opcode
cache support does not apply to 5.5 and o+ as it already supports
quite well, minus the remaining issues (see Matt's post earlier this
week).But again, I am not trying to stop o+ being in core, but the contrary.
No, but you are certainly trying to delay it by suggesting that the
current RFC needs to be rewritten and presumably voting restarted at
which point you can shout louder about how much this is delaying the 5.5
release because you will have added a month of purely process time to
the mix.
The fact is that the current release managers support delaying the
release on the chance that we can get a stable opcode cache into this
release and there is decent majority support for this approach according
to our own process however faulty it may be, so I would ask you to stand
down and let us do our thing instead of getting in the way.
-Rasmus
On Sun, Mar 3, 2013 at 8:41 AM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:The
first step towards integration is getting it in.That does not guarantee that further steps can be done, from a timely
manner.There is never any such guarantee and the current results of the vote
clearly says that the majority of people are fine with a delayed 5.5
release.
"The majority" yes. The accessors proposal also had "the majority" in
favor, but that did not suffice. As of now this RFC does not have a 2/3
majority for the delay. And, as I already pointed out, I really think that
this RFC should go by a 2/3 vote, as it is both a very large change AND a
release delay.
But regardless of that, could somebody maybe point out where the "it may
require a 1-2 month delay" estimation in the RFC comes from? Somewhere
Rasmus said that the integration will not be tight and just a "30 minute
cleanup". I guess that was a bit exaggerated and may take a bit longer, but
in the same order of magnitude (like 3 hours instead of 30 minutes). By
that estimate the vote ends today and we can have ZO+ bundled in one or two
days. To let the change sink a bit, fix a few bugs that turn up and figure
out some questions like naming and default configuration one may need
another week, or maybe two. Then we should already be able to go for a beta
release. Everything else can be ironed out later (it's just a beta after
all and after that we have a good bit of time to fix issues that turn up).
Or did I miss something?
Nikita
Nikita,
The 1-2 month estimation, is taken from about 50cm behind the fingers
typing this email, aka my gut J. It’s quite possible it’ll take much less,
or no time at all; But it’s possible that once we include it, a lot more
people test it, and we’ll get some feedback/requests/bugs that require
attention and additional RC’s – that we would otherwise not have.
Zeev
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Thursday, March 07, 2013 6:02 PM
To: Rasmus Lerdorf
Cc: Pierre Joye; Zeev Suraski; Laruence; PHP Developers Mailing List
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distribution
The
first step towards integration is getting it in.
That does not guarantee that further steps can be done, from a timely
manner.
There is never any such guarantee and the current results of the vote
clearly says that the majority of people are fine with a delayed 5.5
release.
"The majority" yes. The accessors proposal also had "the majority" in
favor, but that did not suffice. As of now this RFC does not have a 2/3
majority for the delay. And, as I already pointed out, I really think that
this RFC should go by a 2/3 vote, as it is both a very large change AND a
release delay.
But regardless of that, could somebody maybe point out where the "it may
require a 1-2 month delay" estimation in the RFC comes from? Somewhere
Rasmus said that the integration will not be tight and just a "30 minute
cleanup". I guess that was a bit exaggerated and may take a bit longer, but
in the same order of magnitude (like 3 hours instead of 30 minutes). By
that estimate the vote ends today and we can have ZO+ bundled in one or two
days. To let the change sink a bit, fix a few bugs that turn up and figure
out some questions like naming and default configuration one may need
another week, or maybe two. Then we should already be able to go for a beta
release. Everything else can be ironed out later (it's just a beta after
all and after that we have a good bit of time to fix issues that turn up).
Or did I miss something?
Nikita
Nikita,
The 1-2 month estimation, is taken from about 50cm behind the fingers
typing this email, aka my gut J. It’s quite possible it’ll take much
less, or no time at all; But it’s possible that once we include it, a lot
more people test it, and we’ll get some feedback/requests/bugs that require
attention and additional RC’s – that we would otherwise not have.Zeev
That makes sense, thanks. So just to be sure I got it right, we can expect
a swift beta, but anticipate that we'll need more releases after that to
fix issues that turn up?
Nikita
Nikita,
The 1-2 month estimation, is taken from about 50cm behind the fingers typing
this email, aka my gut J. It’s quite possible it’ll take much less, or no
time at all; But it’s possible that once we include it, a lot more people
test it, and we’ll get some feedback/requests/bugs that require attention
and additional RC’s – that we would otherwise not have.
You would have got much more feedback by doing pecl releases from day
one. Many people began to test it with the 1st pecl release.
Cheers,
Pierre
@pierrejoye
hi,
"The majority" yes. The accessors proposal also had "the majority" in favor,
but that did not suffice. As of now this RFC does not have a 2/3 majority
for the delay. And, as I already pointed out, I really think that this RFC
should go by a 2/3 vote, as it is both a very large change AND a release
delay.
I fully agree here. Bundling a default opcode cache (enabled by
default or not) is not a small decision and drastically affect the
future of PHP. The way it was handled was by far not ideal (last was
to edit the RFC during the voting phase without restarting the votes)
and I have some doubts about the openness of its future development.
But regardless of that, could somebody maybe point out where the "it may
require a 1-2 month delay" estimation in the RFC comes from?
An estimation, which is already not valid anymore. We are off the two
months. That's also why the beta1 planed today has been replaced with
an alpha instead.
Somewhere
Rasmus said that the integration will not be tight and just a "30 minute
cleanup". I guess that was a bit exaggerated and may take a bit longer,
what takes longer is to stabilize it, there is no integration work
being done right now, as far as I can tell. Latest issues spotted in
our tests are visible in the report #63472.
but
in the same order of magnitude (like 3 hours instead of 30 minutes). By that
estimate the vote ends today and we can have ZO+ bundled in one or two days.
To let the change sink a bit, fix a few bugs that turn up and figure out
some questions like naming and default configuration one may need another
week, or maybe two. Then we should already be able to go for a beta release.
Everything else can be ironed out later (it's just a beta after all and
after that we have a good bit of time to fix issues that turn up). Or did I
miss something?
Not really, betas are for testing and fixing. I did not follow the why
and how we did a release today but having a beta1 now without o+ would
mean that o+ would be 5.5 altogether, not that I would mind it, only a
statement.
That being said, if o+ would have 2/3 of the votes, I think it is
possible to get it stable until 5.5 final, not easy but possible.
Cheers,
Pierre
@pierrejoye
That being said, if o+ would have 2/3 of the votes, I think it is
possible to get it stable until 5.5 final, not easy but possible.
We already covered that. An opcode cache doesn't affect the language
itself. There is no new syntax and no BC issues. Much like a performance
improvement patch that has no effect on the language syntax doesn't need
2/3. Whether it is "major" or not, doesn't matter per the established
voting process. You can't both be a stickler for the details of this
process and then ignore them when they become inconvenient for you.
-Rasmus
That being said, if o+ would have 2/3 of the votes, I think it is
possible to get it stable until 5.5 final, not easy but possible.We already covered that. An opcode cache doesn't affect the language
itself. There is no new syntax and no BC issues.
It affects the whole PHP environment, o+ becomes the de facto
standard, it will replace APC or any other external projects per se in
the long run. If such a move does not affect PHP then I do not know
what else.
Much like a performance
improvement patch that has no effect on the language syntax doesn't need
2/3. Whether it is "major" or not, doesn't matter per the established
voting process. You can't both be a stickler for the details of this
process and then ignore them when they become inconvenient for you.
Oh indeed, I do that. Come on.
But you'd to see that this RFC has been pushed badly in so many ways.
That's not fine. And you also (or should) know that I am (or was) one
of the 1st supporter to push into the core. We put our resources to
test, fix and valid every single change in it since it was OSSed.
However the way it is handled brings doubts, and I really don't want
to have doubts for such a critical piece of the PHP environment.
Cheers,
Pierre
@pierrejoye
Rasmus,
We already covered that. An opcode cache doesn't affect the language
itself. There is no new syntax and no BC issues. Much like a performance
improvement patch that has no effect on the language syntax doesn't need
2/3. Whether it is "major" or not, doesn't matter per the established
voting process. You can't both be a stickler for the details of this
process and then ignore them when they become inconvenient for you.
To be fair, we did cover it, and we didn't come to a consensus. There were
a few people like yourself who believe it's not a language change and hence
requires 2/3... But there are a lot of other people (many who are raising
their hands now) who do believe it's a language level change and hence
requires 2/3. Sure, it doesn't effect syntax. But it can be considered a BC
change, as the internal zend API changes (not in terms of signatures, but
behaviors).
All I'm saying here is that while we did discuss it, no consensus was
achieved. So I don't think it's fair to say "we already covered that".
Anthony
PS: How would we resolve something like this? Would it require a 2/3
meta-vote to determine if something needs a 2/3 vote? Seems like we're
hitting a limit of the RFC here that perhaps should be refactored...
Perhaps make everything require a 2/3 vote, and not have a distinction...
Anthony,
As a rule of thumb, if the language syntax doesn’t change, it doesn’t need
a 2/3 vote.
How do I know? I asked for this special majority in the first place. It
was designed to protect the language from becoming the kitchen sink of
programming languages, not from making architectural progress.
If we need to amend the original voting RFC text so that it’s clearer –
let’s do that. Right now it’s slightly ambiguous because it mentions
‘language syntax’ as an example, instead of outright saying that it’s about
that, period.
Zeev
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Thursday, March 07, 2013 6:44 PM
To: Rasmus Lerdorf
Cc: Pierre Joye; Nikita Popov; Zeev Suraski; Laruence; PHP Developers
Mailing List
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distribution
Rasmus,
We already covered that. An opcode cache doesn't affect the language
itself. There is no new syntax and no BC issues. Much like a performance
improvement patch that has no effect on the language syntax doesn't need
2/3. Whether it is "major" or not, doesn't matter per the established
voting process. You can't both be a stickler for the details of this
process and then ignore them when they become inconvenient for you.
To be fair, we did cover it, and we didn't come to a consensus. There were
a few people like yourself who believe it's not a language change and hence
requires 2/3... But there are a lot of other people (many who are raising
their hands now) who do believe it's a language level change and hence
requires 2/3. Sure, it doesn't effect syntax. But it can be considered a BC
change, as the internal zend API changes (not in terms of signatures, but
behaviors).
All I'm saying here is that while we did discuss it, no consensus was
achieved. So I don't think it's fair to say "we already covered that".
Anthony
PS: How would we resolve something like this? Would it require a 2/3
meta-vote to determine if something needs a 2/3 vote? Seems like we're
hitting a limit of the RFC here that perhaps should be refactored...
Perhaps make everything require a 2/3 vote, and not have a distinction...
Zeev,
As a rule of thumb, if the language syntax doesn’t change, it doesn’t need
a 2/3 vote.
How do I know? I asked for this special majority in the first place. It
was designed to protect the language from becoming the kitchen sink of
programming languages, not from making architectural progress.If we need to amend the original voting RFC text so that it’s clearer –
let’s do that. Right now it’s slightly ambiguous because it mentions
‘language syntax’ as an example, instead of outright saying that it’s about
that, period.
Ambiguous writing is no excuse. People vote based on what is written, not
what was intended. Clarifying after the fact the intentions is not how RFCs
are designed to work. The point is that there's supposed to be clarity in
the text. And considering that the text is pretty clear that any change
affecting the language itself must have 2/3 majority, the question is not
what was intended by that statement, but if adopting ZO+ affects the
language (by interpretation).
So far, from what I've seen, you and Rasmus are the major people backing
the "this is not a language change" camp. In the other camp, there are
several people who have stood up and said that it does appear to be a
language change. I'm not trying to draw lines in the sand, but I'm trying
to point out that we have a disagreement that needs to be resolved.
Hand waving and saying "it's not what I meant by that line" shows nothing
but disrespect for the system and for everyone who participates in it...
So my proposal is to slow down for a minute and not call this RFC accepted
or not until we can come to some consensus as to if it classifies as a
language change or not... Better to clarify for the health of the project
than to plow through and risk causing further strife...
Anthony
So my proposal is to slow down for a minute and not call this RFC
accepted or not until we can come to some consensus as to if it
classifies as a language change or not... Better to clarify for the
health of the project than to plow through and risk causing further
strife...
And how do you propose we do that? Vote on it? Will that vote need 2/3
as well? I think most of us accepted that language-level changes meant
syntax changes. Things that add new features to the language itself.
For example, interned strings in 5.4 was a major change as well and it
broke a bunch of things. I don't think we even bothered with an RFC for
it much less a vote since it was a really worthwhile performance
improvement which didn't affect the language at all other than the fact
that it broke a bunch of things, but once we worked out the bugs and
opcode caches eventually figured out how to support it, it became
invisible to the user. I don't see how adding an opcode cache is any
different. In fact adding this opcode cache will have less of an effect
than interned strings did since it doesn't touch the internals of the
engine anywhere near as much.
-Rasmus
So my proposal is to slow down for a minute and not call this RFC
accepted or not until we can come to some consensus as to if it
classifies as a language change or not... Better to clarify for the
health of the project than to plow through and risk causing further
strife...And how do you propose we do that? Vote on it? Will that vote need 2/3
as well? I think most of us accepted that language-level changes meant
syntax changes. Things that add new features to the language itself.
I think the only thing requiring a 2/3 vote would be the decision on
wheather to enable it by default or not. As long as it's in ext/
and not enabled a 50% should be sufficient.
So my proposal is to slow down for a minute and not call this RFC
accepted or not until we can come to some consensus as to if it
classifies as a language change or not... Better to clarify for the
health of the project than to plow through and risk causing further
strife...And how do you propose we do that? Vote on it? Will that vote need 2/3
as well? I think most of us accepted that language-level changes meant
syntax changes. Things that add new features to the language itself.I think the only thing requiring a 2/3 vote would be the decision on
wheather to enable it by default or not. As long as it's in ext/
and not enabled a 50% should be sufficient.
Shouldn't we be focusing on how this makes PHP better? And not nitpick
about a percentage point or two?
This makes PHP better. Please, PHP, add it to 5.5.
Regards,
Philip
I think the only thing requiring a 2/3 vote would be the decision on
wheather to enable it by default or not. As long as it's in ext/
and not enabled a 50% should be sufficient.Shouldn't we be focusing on how this makes PHP better? And not nitpick
about a percentage point or two?
I agree, no need for lawyers and nitpicking.
Philip,
Shouldn't we be focusing on how this makes PHP better? And not nitpick
about a percentage point or two?
Well, this passed with 62.8%. Property accessors failed with 60.7%. The
target for acceptance is 66.6%. So 3.8% is enough to throw away, but 5.9%
isn't?
I think the point of this discussion is that rules are rules for a reason.
You can't be high and holy and deny one RFC judiciously, and then hand-wave
and say the next RFC doesn't matter because the intention is there (or
whatever rationale is).
Either we stick to the rules, or we throw them out and install a BDFL.
Either way, I don't care. I just think the current
they-sometimes-matter-depending-on-who-and-when-it-is-raised stance is
deeper than BS, it's dangerous and is actively turning away contributors
(as well as harming the project)...
Anthony
Well, this passed with 62.8%. Property accessors failed with 60.7%. The
target for acceptance is 66.6%. So 3.8% is enough to throw away, but 5.9%
isn't?
94% voted to integrate ZO+.
Either we stick to the rules, or we throw them out and install a BDFL.
Either way, I don't care. I just think the current
they-sometimes-matter-depending-on-who-and-when-it-is-raised stance is
deeper than BS, it's dangerous and is actively turning away contributors
(as well as harming the project)...
Oh, please...
Arpad
Philip,
Shouldn't we be focusing on how this makes PHP better? And not nitpick
about a percentage point or two?
Well, this passed with 62.8%. Property accessors failed with 60.7%. The
target for acceptance is 66.6%. So 3.8% is enough to throw away, but 5.9%
isn't?I think the point of this discussion is that rules are rules for a reason.
You can't be high and holy and deny one RFC judiciously, and then hand-wave
and say the next RFC doesn't matter because the intention is there (or
whatever rationale is).Either we stick to the rules, or we throw them out and install a BDFL.
Either way, I don't care. I just think the current
they-sometimes-matter-depending-on-who-and-when-it-is-raised stance is
deeper than BS, it's dangerous and is actively turning away contributors
(as well as harming the project)…
Hello Anthony,
Good points. And the vague release/voting RFCs also contribute to this.
And FWIW, I think PHP needs a BDFL, but we'll have to convince the one
potential candidate to agree. :)
Regards,
Philip
-----Original Message-----
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Thursday, March 07, 2013 1:58 PM
To: Philip Olson
Cc: David Soria Parra; internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distributionPhilip,
Shouldn't we be focusing on how this makes PHP better? And not nitpick
about a percentage point or two?
Well, this passed with 62.8%. Property accessors failed with 60.7%. The
target
for acceptance is 66.6%. So 3.8% is enough to throw away, but 5.9% isn't?I think the point of this discussion is that rules are rules for a
reason.
You can't be high and holy and deny one RFC judiciously, and then hand-
wave and say the next RFC doesn't matter because the intention is there
(or
whatever rationale is).
I have to say I wasn't sure whether to laugh or cry at some of the
ludicrous statements that have been made here.
The 2/3 vote rule was meant to protect the language from not becoming
bloated, i.e. language syntax feature creep. This has been a serious
concern for many of us over the past years with just an ever increasing
flood of new language syntax suggestions coming in. I think very few of us
looked at that as a catch-all for any infrastructure change in PHP incl.
evolving PHP extensions, core runtime changes, etc..
The 62.8% comparison to 60.7% is the most out of touch thing I've read on
this mailing list in a long time. If you're talking about pure feature
yay/nay then 94% have given a yay to this "feature". The split is the
timing.
And as far as timing is concerned I do not see how this whole thing falls
into the 2/3 vote for "new language syntax/prevent feature creep rule".
Many times in the past have we aligned new PHP versions with runtime
improvements esp. as they are often exciting and beneficial to most of our
audience. I don't see why we wouldn't do that given that the cost is
pretty minimal and the benefit to our audience is high.
Andi
The 62.8% comparison to 60.7% is the most out of touch thing I've read on
this mailing list in a long time. If you're talking about pure feature
yay/nay then 94% have given a yay to this "feature". The split is the
timing.
Right, the split is timing, how it is and was done, etc. But now it is
just pushing hard to get in 5.5 misusing both the RFC and the voting
process. And that is what is really bad in this whole thing. As you
hopefully know that I am a huge fan of getting o+ in the core, and
pushed most of our resources to make that possible asap, but not under
all conditions (IIIRC: remember why some well known engine devs left
us some years ago?).
Cheers,
Pierre
@pierrejoye
The 62.8% comparison to 60.7% is the most out of touch thing I've read on
this mailing list in a long time. If you're talking about pure feature
yay/nay then 94% have given a yay to this "feature". The split is the
timing.
Sorry, but math is not liable to what is being measured by a percentage. So
to this point if there is something being done without 2/3 approval, then
its wrong.
Does not matter what it is, who is proposing and who likes it or not.
And as far as timing is concerned I do not see how this whole thing falls
into the 2/3 vote for "new language syntax/prevent feature creep rule".
Many times in the past have we aligned new PHP versions with runtime
improvements esp. as they are often exciting and beneficial to most of our
audience. I don't see why we wouldn't do that given that the cost is
pretty minimal and the benefit to our audience is high.
I'm sorry, but Anthony's example is spot on for this. Property accessors
matter a lot to me and will benefit all frameworks and people who use them
there was no special treatment there and there should be no special
treatment here.
I'm right now oblivious to what is being voted or not in this case, but
ignoring
a defined 2/3 rule is clearly wrong. Either remove rules or follow them
otherwise they
become useless noise.
--
Rafael Dohms
PHP Evangelist and Community Leader
http://doh.ms
http://wwwamsterdamphp.nl
-----Original Message-----
From: Rafael Dohms [mailto:listas@rafaeldohms.com.br]
Sent: Friday, March 08, 2013 2:52 PM
To: Andi Gutmans
Cc: Anthony Ferrara; Philip Olson; David Soria Parra; PHP internals
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distributionThe 62.8% comparison to 60.7% is the most out of touch thing I've read
on this mailing list in a long time. If you're talking about pure
feature yay/nay then 94% have given a yay to this "feature". The split
is the timing.Sorry, but math is not liable to what is being measured by a percentage.
So to
this point if there is something being done without 2/3 approval, then
its wrong.
Rafael,
You seem to be a bit misinformed here. RFCs actually do NOT require 2/3
majority by default, it's left for special cases only. The default is
50%+1. See for yourself - https://wiki.php.net/rfc/voting
There was a bit of discussion on whether or not including Optimizer+ in
PHP is an RFC that falls in the special 2/3 requirement or not. We'll
talk about that in a sec, but it's not really important at all as for this
particular question - 94%, 66 out of 70 voters, voted in favor.
There's absolutely no question that changing PHP's release cycle does
not require a 2/3 vote. Let's look for a second what the voting RFC has
to say about it:
=== Required Majority ===
Given that changes to languages (as opposed to changes to apps or even
frameworks) are for the most part irreversible - the purpose of the vote
is to ensure that there's strong support for the proposed feature. It
needs to be clear that there are a lot more people actively supporting the
proposal, vs. people actively opposing it. We also need to ensure, as much
as possible, that the decision isn't based on some arbitrary circumstances
(such as a temporary marginal majority for a certain school of thought).
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'.
I know the text pretty well, I wrote it, and when I wrote it - I meant
what I said. It's there to protect against changes to the language
which are irreversible. The one thing I regret is that the phrasing
around what constitutes 'a feature affecting the language itself' was left
a bit vague, but one could definitely argue that language syntax and
language behavior are what we're talking about here. Implementation
details, release timelines, included or excluded extensions - are most
certainly not. There's nothing irreversible about them.
Zeev
I'm right now oblivious to what is being voted or not in this case,
but ignoring a defined 2/3 rule is clearly wrong. Either remove rules or follow them otherwise they become useless noise.
As far as I understand the RFC is a process to accept or reject features.
The question that falls in the cracks is if a new feature can delay the release process.
https://wiki.php.net/rfc/releaseprocess
In this case, I think it should. Every law/rule has exceptions, PHP probably needs a dictator or appointed judge(s).
So my proposal is to slow down for a minute and not call this RFC
accepted or not until we can come to some consensus as to if it
classifies as a language change or not... Better to clarify for the
health of the project than to plow through and risk causing further
strife...And how do you propose we do that? Vote on it? Will that vote need 2/3
as well? I think most of us accepted that language-level changes meant
syntax changes. Things that add new features to the language itself.I think the only thing requiring a 2/3 vote would be the decision on
wheather to enable it by default or not. As long as it's in ext/
and not enabled a 50% should be sufficient.
Not that I worry, but how do we reach that conclusion?
Rasmus had a good point. We didn't even vote about interned strings
(and that's a good thing), and I'm doubtful that if we did find it
necessary to vote for it, we'd find that more than 51% is needed. How
is enabling O+ different? Or do we need a vote, and even a 2/3 vote,
for every significant perf improvement?
Again, I don't really worry - given that 94% of voters voted in favor
of embracing O+ (and honestly I'd love to get wider user feedback from
5.5 evaluators before we take this call) - but I'm worried that 2/3
voting requirement will become arbitrary, and not what it was designed
to serve - a way from protecting the language from a flood of
irreversible changes.
Zeev
I think the only thing requiring a 2/3 vote would be the decision on
wheather to enable it by default or not. As long as it's in ext/
and not enabled a 50% should be sufficient.
I disagree that it is the only point requiring 2/3, but yes, enabling
it by default must have 2/3.
Cheers,
Pierre
@pierrejoye
Anthony,
94% of the votes voted in favor of integrating O+ into PHP, which is well
above 2/3, it’s almost 3/3. The only open question was about timeline.
And no matter how we twist it, whether it happens now or in a year has
ABSOLUTELY nothing to do with whether or not it’s a language change. In
other words, if I phrased the RFC differently, and only asked who’s in
favor vs. who’s against – it would get a 94% vote in favor, easily blowing
past both the 51% barrier as well as the 67% barrier. A 2nd RFC, asking
people to vote about the timeline – would have gotten 44 vs 22, which
happens to be 2/3, but clearly, would not have required more than 51% since
it’s a timeline question, not a language change question.
I’m afraid that’s as far as I’m willing to play this game of bureaucracy.
The voting RFC wasn’t designed to turn PHP into The House, or a courtroom.
There’s absolutely NO WAY we can reach consensus, and there’s no way the
overwhelming majority would agree to paralysis imposed by a tiny minority.
Let’s put it to rest, we all have better things to do with our time.
Zeev
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Thursday, March 07, 2013 7:02 PM
To: Zeev Suraski
Cc: Rasmus Lerdorf; Nikita Popov; Laruence; PHP Developers Mailing List
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distribution
Zeev,
As a rule of thumb, if the language syntax doesn’t change, it doesn’t need
a 2/3 vote.
How do I know? I asked for this special majority in the first place. It
was designed to protect the language from becoming the kitchen sink of
programming languages, not from making architectural progress.
If we need to amend the original voting RFC text so that it’s clearer –
let’s do that. Right now it’s slightly ambiguous because it mentions
‘language syntax’ as an example, instead of outright saying that it’s about
that, period.
Ambiguous writing is no excuse. People vote based on what is written, not
what was intended. Clarifying after the fact the intentions is not how RFCs
are designed to work. The point is that there's supposed to be clarity in
the text. And considering that the text is pretty clear that any change
affecting the language itself must have 2/3 majority, the question is not
what was intended by that statement, but if adopting ZO+ affects the
language (by interpretation).
So far, from what I've seen, you and Rasmus are the major people backing
the "this is not a language change" camp. In the other camp, there are
several people who have stood up and said that it does appear to be a
language change. I'm not trying to draw lines in the sand, but I'm trying
to point out that we have a disagreement that needs to be resolved.
Hand waving and saying "it's not what I meant by that line" shows nothing
but disrespect for the system and for everyone who participates in it...
So my proposal is to slow down for a minute and not call this RFC accepted
or not until we can come to some consensus as to if it classifies as a
language change or not... Better to clarify for the health of the project
than to plow through and risk causing further strife...
Anthony
94% of the votes voted in favor of integrating O+ into PHP, which is well
above 2/3, it’s almost 3/3.
44 for 5.5 + delay
22 for no delay (aka 5.6)
4 for not at all in the current sate
Sorry but don't use numbers badly to cover your goals.
The only open question was about timeline.
It is the main question, not the last open (there are many).
And no matter how we twist it, whether it happens now or in a year has
ABSOLUTELY nothing to do with whether or not it’s a language change. In
other words, if I phrased the RFC differently, and only asked who’s in
favor vs. who’s against – it would get a 94% vote in favor,
easily blowing
past both the 51% barrier as well as the 67% barrier. A 2nd RFC, asking
people to vote about the timeline – would have gotten 44 vs 22, which
happens to be 2/3, but clearly, would not have required more than 51% since
it’s a timeline question, not a language change question.
It is clearly not as clear as you think.
I’m afraid that’s as far as I’m willing to play this game of bureaucracy.
The voting RFC wasn’t designed to turn PHP into The House, or a courtroom.
There’s absolutely NO WAY we can reach consensus, and there’s no way the
overwhelming majority would agree to paralysis imposed by a tiny minority.
Let’s put it to rest, we all have better things to do with our time.
Yes, but what should be put on rest is not the RFCs process, which
work out of the box for 99.99% but the way you habdle it and the total
lack of respect for the different opinions raised here or on other
lists. That'd to end at some point.
Cheers,
Pierre
@pierrejoye
That being said, if o+ would have 2/3 of the votes, I think it is
possible to get it stable until 5.5 final, not easy but possible.We already covered that. An opcode cache doesn't affect the language
itself. There is no new syntax and no BC issues. Much like a performance
improvement patch that has no effect on the language syntax doesn't need
2/3. Whether it is "major" or not, doesn't matter per the established
voting process. You can't both be a stickler for the details of this
process and then ignore them when they become inconvenient for you.
btw, I would even have included phar as affecting the language, as
even if you don't use it at all in your code, it affects how php
behaves. We had many issues related to phar while it was not used at
all in the code (due to the hooks). That's not exactly the same thing
than o+ but it has the same kind of possible impacts.
--
Pierre
@pierrejoye
That being said, if o+ would have 2/3 of the votes, I think it is
possible to get it stable until 5.5 final, not easy but possible.We already covered that. An opcode cache doesn't affect the language
itself. There is no new syntax and no BC issues. Much like a performance
improvement patch that has no effect on the language syntax doesn't need
2/3. Whether it is "major" or not, doesn't matter per the established
voting process. You can't both be a stickler for the details of this
process and then ignore them when they become inconvenient for you.btw, I would even have included phar as affecting the language, as
even if you don't use it at all in your code, it affects how php
behaves. We had many issues related to phar while it was not used at
all in the code (due to the hooks). That's not exactly the same thing
than o+ but it has the same kind of possible impacts.
And there comes the true definition of "affects language behavior".
We still don't agree each other of what a "major" change, and a "minor" one
are, and : do we talk about user-level changes, or internals changes ? Or
both ?
That definitely needs to be clarified, or Anthony's idea of no distinction
on any RFC and make them require 2/3 to be accepted as well.
Julien.Pauli
what takes longer is to stabilize it, there is no integration work
being done right now, as far as I can tell. Latest issues spotted in
our tests are visible in the report #63472.
I mean #64372
--
Pierre
@pierrejoye
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Sunday, March 03, 2013 9:26 AM
To: Zeev Suraski
Cc: Laruence; PHP Developers Mailing List
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distributionHow "Don't integrate Optimizer+ to PHP" can be remotely related to
the available of o+ via PECL?Actually it seems as if some of the original text got lost when I
switched to the active vote, but it used to read 'Don't integrate
Optimizer+ to PHP, release only in PECL'. My bad.No offense and pls do not see what I will say here as an attempt to
block it, as I
really want o+ in core.I think this RFC should be fixed (fix wording to represent the actual
actions,
s,integration,bundling&cleanup,), votes options added to cover what has
been
discussed. Add a roadmap as well for the further steps that
can/could/will be
taken to make o+ even better while being in core.
Pierre,
The whole 'integration' point is well defined in the RFC under the 'PHP
5.5.0 section'. There's no tight integration on the table. The delay is
also defined as anywhere between 0 and 1-2 months, it's not open-ended.
I added a bit of clarifying text to the 3rd option, to ensure people
understand this would mean we make it avail through PECL.
I'm not going to add additional voting options at this point. Look
around, the a strong majority of devs and the vast majority of core devs
wants it in 5.5.0, and not continue hashing with bureaucracy. We'd really
love to be done with the discussion instead of restarting it.
Zeev
Based on the overwhelming response, the vote is now open J
https://wiki.php.net/rfc/optimizerplus
Voting ends March 7th.
What kind of majority does this vote require? 50% or 2/3?
Thanks,
Nikita
No syntax changes, so regular majority as far as I can tell.
Sent from my mobile
Based on the overwhelming response, the vote is now open J
https://wiki.php.net/rfc/optimizerplus
Voting ends March 7th.
What kind of majority does this vote require? 50% or 2/3?
Thanks,
Nikita
No syntax changes, so regular majority as far as I can tell.
Except if you want real integration included in this vote, as it will
or may affect the engine, 2/3 will be required then.
--
Pierre
@pierrejoye
No.
First, read what 'integration' means in the RFC or in the excerpt
Chris was nice enough to send you. It means including the extension,
which doesn't fall under "changing the language" in the voting RFC in
any way.
Secondly, even if&when we do propose to integrate it more tightly -
it's debatable whether it constitutes a language change that requires
a 2/3 majority. Even though I'm sure that if we manage to show
substantial benefits from doing that in the future well get a lot more
than 67% in favor...
- Sent from my mobile
No syntax changes, so regular majority as far as I can tell.
Except if you want real integration included in this vote, as it will
or may affect the engine, 2/3 will be required then.--
Pierre@pierrejoye
No.
First, read what 'integration' means in the RFC or in the excerpt
Chris was nice enough to send you. It means including the extension,
which doesn't fall under "changing the language" in the voting RFC in
any way.
That's not integration, that's bundling with some cleanups. Let call a
cat a cat.
Secondly, even if&when we do propose to integrate it more tightly -
it's debatable whether it constitutes a language change that requires
a 2/3 majority. Even though I'm sure that if we manage to show
substantial benefits from doing that in the future well get a lot more
than 67% in favor...
Please do not get me wrong, I was the 1st to propose a tight
integration in a 2nd phase, and to push as much resources as we can to
get o+ tested and ready in time. However it does not mean that I can
or will simply say yes to any kind of move just because an opcode
cache being bundled is uber sexy. It is, but that's not a small step
and that's something that has to be done the right way, by all means.
About debating if something is tightly integrated or enabled by
default, phar is one of the examples causing issues even if one does
not use it. To think about having a similar case at the engine level
is not something I want to take softly but carefully.
On a good news side, recent fixes solved a couple of issues we got
during testing (thanks Dmitry). One critical remains, Matt will post a
summary later today.
Cheers,
Pierre
@pierrejoye
No syntax changes, so regular majority as far as I can tell.
Sent from my mobile
It's not a syntax change, but it is a very, very large engine change. Yes,
it does not touch the Zend engine itself, but it adds a large amount of new
code that is close to the engine. People doing engine changes will need to
modify it too (thus it is quasi part of the engine, even if it lives in a
separate directory). All existing core devs will have to study and
understand the code. All new developers have an additional piece of very
complex code to study before they can start making core changes.
So no, this is not a syntax change, but it is a engine change with a by
far larger impact than any of the other things that have been introduced
in PHP 5.5 (like generators or finally).
That's why I asked about the type of vote. I'm never quite sure which kind
of vote something requires (maybe we could clarify that paragraph in the
voting RFC a bit?)
Thanks, Nikita
No syntax changes, so regular majority as far as I can tell.
Sent from my mobile
It's not a syntax change, but it is a very, very large engine change. Yes,
it does not touch the Zend engine itself, but it adds a large amount of new
code that is close to the engine. People doing engine changes will need to
modify it too (thus it is quasi part of the engine, even if it lives in a
separate directory). All existing core devs will have to study and
understand the code. All new developers have an additional piece of very
complex code to study before they can start making core changes.
Which arguable core devs should have been doing for years but weren't.
The issues you need to be aware of with ZO+ aren't any different from
what you need to be aware of with any opcode cache and that has been the
cause of the big lag between new PHP releases and support from opcode
caches. Getting everyone on the same page with a single de-facto
standard opcode cache is going to be a huge win and the sooner we can
get there, the better.
-Rasmus
I'm very sure users will not complain if 5.5 is delayed for a few months.
Most websites will not be installing 5.5 immediately after it has been
released.
My take on this is that we integrate O+ in to core, iron out all the issues
and then release a stable 5.5.
If O+ will improve the performance of PHP then I'm sure users will love it.
__
Raymond
No syntax changes, so regular majority as far as I can tell.
Sent from my mobile
It's not a syntax change, but it is a very, very large engine change. Yes,
it does not touch the Zend engine itself, but it adds a large amount of new
code that is close to the engine. People doing engine changes will need to
modify it too (thus it is quasi part of the engine, even if it lives in a
separate directory). All existing core devs will have to study and
understand the code. All new developers have an additional piece of very
complex code to study before they can start making core changes.So no, this is not a syntax change, but it is a engine change with a by
far larger impact than any of the other things that have been introduced
in PHP 5.5 (like generators or finally).That's why I asked about the type of vote. I'm never quite sure which kind
of vote something requires (maybe we could clarify that paragraph in the
voting RFC a bit?)Thanks, Nikita
Raymond Irving in php.internals (Thu, 28 Feb 2013 13:56:11 -0500):
I'm very sure users will not complain if 5.5 is delayed for a few months.
Most websites will not be installing 5.5 immediately after it has been
released.
On the contrary: many users will welcome it because it delays the EOL of
PHP 5.3 as well. The outcome of a previous vote was that PHP 5.3 would
become unsupported within, say, 14 months from now. An unbelievable
short time frame given the fact that many sites did not even migrate to
PHP 5.3.
JAn
Raymond Irving in php.internals (Thu, 28 Feb 2013 13:56:11 -0500):
I'm very sure users will not complain if 5.5 is delayed for a few months.
Most websites will not be installing 5.5 immediately after it has been
released.On the contrary: many users will welcome it because it delays the EOL of
PHP 5.3 as well. The outcome of a previous vote was that PHP 5.3 would
become unsupported within, say, 14 months from now. An unbelievable
short time frame given the fact that many sites did not even migrate to
PHP 5.3.JAn
--
There's all this talk about the lack of 5.4 adoption being related to the lack of an opcode cache. I think that's ridiculous. Most shared hosts that I know about do not even offer opcode caching, so that can't be the reason why they haven't upgraded.
I know of one host that said it was because Zend Guard no longer supported BSD after 5.2 (don't know if it has since been added back in because that host has since upgraded to 5.3). Others work with LTS distro releases like Ubuntu and Red Hat, neither of which are on 5.4 either. The next Ubuntu LTS release won't be out until April 2014, so don't expect a surge in 5.4 adoption (or whatever version 14.04 comes with) for at least another year.
For me personally, I'm running sites on 5.2 and 5.3. I am unable to upgrade to 5.4 and beyond because of the removal of register_globals and magic_quotes_gpc. I am not complaining that they were removed. Those two settings have been a huge pain in the backside for years, and I'm glad they're gone. But the legacy software I have to maintain was written assuming they were available and on. It will take a very long time to fix and update all that code to run on 5.4.
Cheers,
David
Hi!
It's not a syntax change, but it is a very, very large engine change. Yes,
it does not touch the Zend engine itself, but it adds a large amount of new
code that is close to the engine. People doing engine changes will need to
modify it too (thus it is quasi part of the engine, even if it lives in a
I'm not sure how it makes sense - people changing the engine had to
modify SPL or libxml or SOAP extension, for example - so now SOAP is
part of the engine? Since engine is underlying API, if you modify the
engine then you may have to modify extensions, doesn't mean all
extensions are part of the engine. I find this pretty strained argument.
separate directory). All existing core devs will have to study and
understand the code. All new developers have an additional piece of very
complex code to study before they can start making core changes.
Again, by this logic everything is the engine - if you didn't look at
how PDO works and changed the engine in a way that broke PDO - it's bad,
so by that logic PDO is the engine. And so is pretty much any extension
anybody cares about.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Thu, Feb 28, 2013 at 8:13 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
It's not a syntax change, but it is a very, very large engine change.
Yes,
it does not touch the Zend engine itself, but it adds a large amount of
new
code that is close to the engine. People doing engine changes will need
to
modify it too (thus it is quasi part of the engine, even if it lives in aI'm not sure how it makes sense - people changing the engine had to
modify SPL or libxml or SOAP extension, for example - so now SOAP is
part of the engine? Since engine is underlying API, if you modify the
engine then you may have to modify extensions, doesn't mean all
extensions are part of the engine. I find this pretty strained argument.
The difference between SOAP and ZO+ is the level of integration and
dependency. If you do a change in the ZE there is a very high chance that
you will not have to touch any code in SOAP, but you will quite likely need
to adjust something in ZO+. Phar is the only of the current extensions that
comes anywhere close to this. And ZO+ is still a lot more tightly
integrated than Phar (and you know what a PITA Phar can be...)
If you don't see that ZO+ is an extension that is very tightly integrated
with the ZE and rather sensitive to change, then sorry, can't help you. To
me this seems obvious.
Nikita
Zeev,
No syntax changes, so regular majority as far as I can tell.
However, it does nuke several existing PECL extensions (some fatally). For
example, XDebug has no compatibility with ZendOptimizer+ right now (at
least that I could find, feel free to correct me if I'm wrong here).
And some could argue that shipping with a modification that breaks known
and widely relied upon (if only for development) extensions would fit into
this category.
Since it changes the functionality that extensions experience
(specifically engine extensions), it should be considered an engine
change... The API doesn't change at the syntax level, but the contract
definitely does (preconditions, post conditions and invariants)...
Anthony
However, it does nuke several existing PECL extensions (some fatally).
For example, XDebug has no compatibility with ZendOptimizer+ right now
(at least that I could find, feel free to correct me if I'm wrong
here).
You wouldn't want to run them at the same time anyway... but we do need
to have a look at this as APC+Xdebug worked just fine™
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
Hi!
However, it does nuke several existing PECL extensions (some fatally). For
example, XDebug has no compatibility with ZendOptimizer+ right now (at
least that I could find, feel free to correct me if I'm wrong here).
This of course will have to be fixed before the release. Though right
now I don't see much reason why xdebug would break - did you try it and
if so what happened?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
It shouldn't kill any PECL extensions, most certainly not Xdebug.
Ideally I'd like to get Xdebug compatibility for 5.5 - but even if we can't
make it - there's truth to the assertion you wouldn't want them both at the
same time.
Either way - in the long run O+ and Xdebug will definitely work together,
and in the short run, you can choose one or the other. Also, I think
Rasmus said the combo works for him if he loads O+ first and Xdebug later,
so it may not be completely broken at all. Fwiw, the code it takes to have
Zend Debugger work alongside O+ isn't very complicated and therefore I'm
not at all worried that we'll have a hard time supporting Xdebug. As the
RFC states - that may require some minor engine changes.
Sent from my tablet
Zeev,
No syntax changes, so regular majority as far as I can tell.
However, it does nuke several existing PECL extensions (some fatally). For
example, XDebug has no compatibility with ZendOptimizer+ right now (at
least that I could find, feel free to correct me if I'm wrong here).
And some could argue that shipping with a modification that breaks known
and widely relied upon (if only for development) extensions would fit into
this category.
Since it changes the functionality that extensions experience
(specifically engine extensions), it should be considered an engine
change... The API doesn't change at the syntax level, but the contract
definitely does (preconditions, post conditions and invariants)...
Anthony
It shouldn't kill any PECL extensions, most certainly not Xdebug.
es (preconditions, post conditionj and invariants)...
And what is the reason to still have no pecl release for o+? It should have
been done a month ago.
Hi Zeev,
Am 28.02.2013 um 21:16 schrieb Zeev Suraski zeev@zend.com:
Ideally I'd like to get Xdebug compatibility for 5.5 - but even if we can't
make it - there's truth to the assertion you wouldn't want them both at the
same time.
That’s not entirely true. If you stay as similar as possible to your production environment, your development environment will have an opcode cache as well. And possibly xdebug.
cu,
Lars
Ideally I'd like to get Xdebug compatibility for 5.5 - but even if we can't
make it - there's truth to the assertion you wouldn't want them both at the
same time.That’s not entirely true. If you stay as similar as possible to your production environment, your development environment will have an opcode cache as well. And possibly xdebug.
I run xdebug on 1% of my production servers to a nice stack trace for
errors that reveal themselves in production. Similar to how I run
xhprof on 1% of all web requests.
--
Herman Radtke
@hermanradtke | http://hermanradtke.com
-----Original Message-----
From: Lars Strojny [mailto:lars@strojny.net]
Sent: Tuesday, March 05, 2013 12:31 AM
To: Zeev Suraski
Cc: Anthony Ferrara; Nikita Popov; PHP Developers Mailing List
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distributionHi Zeev,
Am 28.02.2013 um 21:16 schrieb Zeev Suraski zeev@zend.com:
Ideally I'd like to get Xdebug compatibility for 5.5 - but even if we
can't make it - there's truth to the assertion you wouldn't want them
both at the same time.That's not entirely true. If you stay as similar as possible to your
production
environment, your development environment will have an opcode cache as
well. And possibly xdebug.
I agree it's not entirely true, which is why I said there's only 'some'
truth to it :) In other words, I think it's desirable that they would
both work together, but if they don't, it's not the end of the world.
But again, they already work together fairly well and we'll hopefully make
them work together even better.
Zeev
Zeev,
No syntax changes, so regular majority as far as I can tell.
However, it does nuke several existing PECL extensions (some fatally). For
example, XDebug has no compatibility with ZendOptimizer+ right now (at
least that I could find, feel free to correct me if I'm wrong here).
It works fine. You just have to load ZO before xdebug. If you load it
the other way around bad things happen. This wrong load order currently
happens if you toss it in your config file path dir and rely on the
alphabetical load order which is another reason to not have this thing
start with a 'z'.
And some could argue that shipping with a modification that breaks known
and widely relied upon (if only for development) extensions would fit into
this category.
Since the fix for this is trivial, I think this isn't a valid concern.
-Rasmus
Hi!
It works fine. You just have to load ZO before xdebug. If you load it
the other way around bad things happen. This wrong load order currently
Could you describe the bad things? Maybe we could have some checks in
either of them to prevent it... Of course, we could probably make ZO
just check if xdebug is loaded and react accordingly, but maybe we could
resolve it in a more elegant way...
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
It works fine. You just have to load ZO before xdebug. If you load it
the other way around bad things happen. This wrong load order currentlyCould you describe the bad things? Maybe we could have some checks in
either of them to prevent it... Of course, we could probably make ZO
just check if xdebug is loaded and react accordingly, but maybe we could
resolve it in a more elegant way...
Well, I did describe it back on Feb.13 and cc'ed you actually, but it
was a segfault which looked to be caused by a double-free in a piece of
complicated code. It manifested itself on line 203 of this code:
200 } else {
201 list($v, $selector) =
202 $this->variantFromURL($userID) ?:
203 $this->variantForUser($userID) ?:
204 $this->variantForGroup($userID) ?:
205 $this->variantForAdmin($userID) ?:
206 $this->variantForInternal() ?:
207 $this->variantByPercentage($bucketingID) ?:
208 array(self::OFF, 'w');
which, granted, is short-circuited-ternary-abuse, but still. Switching
the ZO/Xdebug load order cleared it up. It didn't happen on every
request and not on a stripped down test case, so it was hard to narrow
down further. But this is often the case for opcode cache-related problems.
The segfault looked like this:
#0 0x00007fc5e636b6b1 in _zval_dtor_func (zvalue=0x7fc5ee784828) at
/home/rlerdorf/php-src/Zend/zend_variables.c:54
54 Z_OBJ_HT_P(zvalue)->del_ref(zvalue TSRMLS_CC);
(gdb) bt
#0 0x00007fc5e636b6b1 in _zval_dtor_func (zvalue=0x7fc5ee784828) at
/home/rlerdorf/php-src/Zend/zend_variables.c:54
#1 0x00007fc5e639f146 in _zval_dtor (execute_data=0x7fc5ebcd3da8) at
/home/rlerdorf/php-src/Zend/zend_variables.h:35
#2 i_zval_ptr_dtor (execute_data=0x7fc5ebcd3da8) at
/home/rlerdorf/php-src/Zend/zend_execute.h:87
#3 zend_leave_helper_SPEC (execute_data=0x7fc5ebcd3da8) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:468
#4 0x00007fc5e63d4cb0 in execute (op_array=0x7fc5ee6d4140) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#5 0x00007fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee6d4140) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#6 0x00007fc5e63e7bf1 in zend_do_fcall_common_helper_SPEC
(execute_data=<value optimized out>)
at /home/rlerdorf/php-src/Zend/zend_vm_execute.h:669
#7 0x00007fc5e63d4cb0 in execute (op_array=0x7fc5ee6cd918) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#8 0x00007fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee6cd918) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#9 0x00007fc5e63e7bf1 in zend_do_fcall_common_helper_SPEC
(execute_data=<value optimized out>)
at /home/rlerdorf/php-src/Zend/zend_vm_execute.h:669
#10 0x00007fc5e63d4cb0 in execute (op_array=0x7fc5ee6c9d98) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#11 0x00007fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee6c9d98) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#12 0x00007fc5e63e7bf1 in zend_do_fcall_common_helper_SPEC
(execute_data=<value optimized out>)
at /home/rlerdorf/php-src/Zend/zend_vm_execute.h:669
#13 0x00007fc5e63d4cb0 in execute (op_array=0x7fc5ee6c5240) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#14 0x00007fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee6c5240) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#15 0x00007fc5e63e7bf1 in zend_do_fcall_common_helper_SPEC
(execute_data=<value optimized out>)
at /home/rlerdorf/php-src/Zend/zend_vm_execute.h:669
#16 0x00007fc5e63d4cb0 in execute (op_array=0x7fc5ee2b4868) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#17 0x00007fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee2b4868) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#18 0x00007fc5e63e7bf1 in zend_do_fcall_common_helper_SPEC
(execute_data=<value optimized out>)
at /home/rlerdorf/php-src/Zend/zend_vm_execute.h:669
#19 0x00007fc5e63d4cb0 in execute (op_array=0x7fc5ee713800) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#20 0x00007fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee713800) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#21 0x00007fc5e63e7bf1 in zend_do_fcall_common_helper_SPEC
(execute_data=<value optimized out>)
at /home/rlerdorf/php-src/Zend/zend_vm_execute.h:669
#22 0x00007fc5e63d4cb0 in execute (op_array=0x7fc5ee6f7e20) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#23 0x00007fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee6f7e20) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#24 0x00007fc5e63e7bf1 in zend_do_fcall_common_helper_SPEC
(execute_data=<value optimized out>)
at /home/rlerdorf/php-src/Zend/zend_vm_execute.h:669
#25 0x00007fc5e63d4cb0 in execute (op_array=0x7fc5ee6f5e50) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#26 0x00007fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee6f5e50) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#27 0x00007fc5e63e7bf1 in zend_do_fcall_common_helper_SPEC
(execute_data=<value optimized out>)
at /home/rlerdorf/php-src/Zend/zend_vm_execute.h:669
#28 0x00007fc5e63d4cb0 in execute (op_array=0x7fc5ee682f30) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#29 0x00007fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee682f30) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#30 0x00007fc5e63e7bf1 in zend_do_fcall_common_helper_SPEC
(execute_data=<value optimized out>)
at /home/rlerdorf/php-src/Zend/zend_vm_execute.h:669
#31 0x00007fc5e63d4cb0 in execute (op_array=0x7fc5ee706080) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#32 0x00007fc5e26289c9 in xdebug_execute (op_array=0x7fc5ee706080) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#33 0x00007fc5e63e7bf1 in zend_do_fcall_common_helper_SPEC
(execute_data=<value optimized out>)
at /home/rlerdorf/php-src/Zend/zend_vm_execute.h:669
#34 0x00007fc5e63d4cb0 in execute (op_array=0x7fc594bf8100) at
/home/rlerdorf/php-src/Zend/zend_vm_execute.h:410
#35 0x00007fc5e26289c9 in xdebug_execute (op_array=0x7fc594bf8100) at
/home/rlerdorf/pecl/xdebug/xdebug.c:1435
#36 0x00007fc5e636ba0d in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/rlerdorf/php-src/Zend/zend.c:1315
#37 0x00007fc5e630f757 in php_execute_script
(primary_file=0x7fff68d654d0) at /home/rlerdorf/php-src/main/main.c:2492
#38 0x00007fc5e6415bc5 in php_handler (r=0x7fc5edf736c8) at
/home/rlerdorf/php-src/sapi/apache2handler/sapi_apache2.c:667
#39 0x00007fc5ebdc1b00 in ap_run_handler ()
#40 0x00007fc5ebdc53be in ap_invoke_handler ()
#41 0x00007fc5ebdd086c in ap_internal_redirect ()
#42 0x00007fc5e67cd7a5 in ?? () from /etc/httpd/modules/mod_rewrite.so
#43 0x00007fc5ebdc1b00 in ap_run_handler ()
#44 0x00007fc5ebdc53be in ap_invoke_handler ()
#45 0x00007fc5ebdd0a30 in ap_process_request ()
#46 0x00007fc5ebdcd8f8 in ?? ()
#47 0x00007fc5ebdc9608 in ap_run_process_connection ()
#48 0x00007fc5ebdd5807 in ?? ()
#49 0x00007fc5ebdd5b1a in ?? ()
#50 0x00007fc5ebdd5e4b in ap_mpm_run ()
#51 0x00007fc5ebdad900 in main ()
Stas,
Just to put things in perspective, if opcode caches with extended info
make it into the opcode cache - it's a bad thing. So it's actually
expected that debuggers and opcode caches would have to be aware of
one another, but at a pretty minimal level. The load order solves it
most probably because then it means Xdebug kicks in first, and
wouldn't pass op arrays to O+. That's guesswork though, we'd have to
ensure that and ideally also have a mechanism to enforce it.
Sent from my tablet
Hi!
It works fine. You just have to load ZO before xdebug. If you load it
the other way around bad things happen. This wrong load order currentlyCould you describe the bad things? Maybe we could have some checks in
either of them to prevent it... Of course, we could probably make ZO
just check if xdebug is loaded and react accordingly, but maybe we could
resolve it in a more elegant way...--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Just to put things in perspective, if opcode caches with extended info
make it into the opcode cache - it's a bad thing. So it's actually
Yeah, we should definitely check for extended info and shortcut
compile_file immediately if that is there. Should be an easy patch, I'll
try to do pull tonight. If that's the problem behind Rasmus' crash, it's
easy to fix.
expected that debuggers and opcode caches would have to be aware of
one another, but at a pretty minimal level. The load order solves it
most probably because then it means Xdebug kicks in first, and
wouldn't pass op arrays to O+. That's guesswork though, we'd have to
ensure that and ideally also have a mechanism to enforce it.
Yeah, that is what I was worried about if there's no other problems
deeper than the extended info one and how to handle it in an elegant
fashion without hardcoding checks for specific names.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Zeev,
No syntax changes, so regular majority as far as I can tell.
However, it does nuke several existing PECL extensions (some fatally). For
example, XDebug has no compatibility with ZendOptimizer+ right now (at
least that I could find, feel free to correct me if I'm wrong here).It works fine. You just have to load ZO before xdebug. If you load it
the other way around bad things happen. This wrong load order currently
happens if you toss it in your config file path dir and rely on the
alphabetical load order which is another reason to not have this thing
start with a 'z'.And some could argue that shipping with a modification that breaks known
and widely relied upon (if only for development) extensions would fit into
this category.Since the fix for this is trivial, I think this isn't a valid concern.
-Rasmus
Hello php.internals,
I've read all the e-mails so far and there are valid points from both
parts but it seems there's a critical thing missing.
What do PHP users want?
I mean, what do sysadmins, programmers and managers want from PHP 5.5?
Here's my personal opinion:
I work in an enterprise so... I want stability (includes bug fixes)
and speed. In this order. Language features are on the third spot, at
least this is the case for PHP 5.5.
We'll get generators and a function for passwords and something I
really don't care about :) Why? Because I won't have a chance to use
them soon and by the time I'll use them PHP will get to version 5.8
most likely. So for me the fact that PHP 5.5 will be delayed a couple
of months is irrelevant.
We upgrade either to use better tools/frameworks or to benefit from
security patches when versions are no longer maintained so unless
something big appears earlier there's no point to upgrade.
Don't get me wrong, those features are great, as much as those in PHP
5.4, yet history tells us that people still didn't made that step to
upgrade to 5.4 yet.
So if those features are not that 'something big' then what is it?
A huge, out of the box, speed bump for production machines.
Could this be done with APC? Most likely, that is if a stable APC were
to be released same time as PHP 5.5. I really don't want to offend
anyone but see what happened with 5.4 and APC.
What I'm trying to say is: if O+ can be added to PHP 5.5 and made
stable, and I do mean production ready which from my understanding is
almost there, then why shouldn't it be done?
But I'm just a single user. Maybe I'm right, maybe I'm wrong. But so
are the other people who replied here so far, they are all only
individuals.
This is a perfect opportunity for testing out the whole: 'ask your
users' thing that me and several other people were talking about.
How expensive would it be, both in time and actual costs, to actually
make this happen? Either setup a poll on php.net or on a third party
service for one-two weeks and ask the users these simple questions
(obviously they could be better, POC ahead):
What do you expect from PHP 5.5? (multiple choice)
- better security
- better stability
- better speed
- more language features
- other <type here>
- all of the above
Do you know what an opcode cache is?
- yes
- no
Would you be ok if PHP 5.5 will not ship in April 2013 but in August
2013 because we want to integrate an opcode cache, a functionality,
which once used could increase the speed of your applications by up to
50% or more*?
- yes
- no
- NOTE: the speed increase is not guaranteed to be the same for all
applications nor it is guaranteed.
Would the fact that PHP 5.5 doesn't ship as originally planed, if the
mentioned integration happens, affect your view about PHP?
- yes
- no
What position do you have in your company?
- developer
- sysadmin
- devops
- manager
- other: <type here>
Are you in a position to influence the upgrade from your current PHP
version to PHP 5.5?
- yes
- no
Afaik every major framework has someone here, on the ML, then we have
Zend and we have some other libraries and so on here as well. Imagine
if all those people would link from their websites to the said poll. I
think it would be a small effort from them but the responses could at
least point out to what users actually want and help you in sorting
this out.
If I offended anyone, which I'm almost sure I did, it was not my
intention, please forgive me.
Thank you all for your hard work on PHP.
Best regards.
Florin Patan
https://github.com/dlsniper
I've read all the e-mails so far and there are valid points from both
parts but it seems there's a critical thing missing.What do PHP users want?
I mean, what do sysadmins, programmers and managers want from PHP 5.5?
Here's my personal opinion:
I work in an enterprise so... I want stability (includes bug fixes)
and speed. In this order. Language features are on the third spot, at
least this is the case for PHP 5.5.We'll get generators and a function for passwords and something I
really don't care about :) Why? Because I won't have a chance to use
them soon and by the time I'll use them PHP will get to version 5.8
most likely. So for me the fact that PHP 5.5 will be delayed a couple
of months is irrelevant.We upgrade either to use better tools/frameworks or to benefit from
security patches when versions are no longer maintained so unless
something big appears earlier there's no point to upgrade.Don't get me wrong, those features are great, as much as those in PHP
5.4, yet history tells us that people still didn't made that step to
upgrade to 5.4 yet.So if those features are not that 'something big' then what is it?
A huge, out of the box, speed bump for production machines.
Could this be done with APC? Most likely, that is if a stable APC were
to be released same time as PHP 5.5. I really don't want to offend
anyone but see what happened with 5.4 and APC.What I'm trying to say is: if O+ can be added to PHP 5.5 and made
stable, and I do mean production ready which from my understanding is
almost there, then why shouldn't it be done?But I'm just a single user. Maybe I'm right, maybe I'm wrong. But so
are the other people who replied here so far, they are all only
individuals.This is a perfect opportunity for testing out the whole: 'ask your
users' thing that me and several other people were talking about.How expensive would it be, both in time and actual costs, to actually
make this happen? Either setup a poll on php.net or on a third party
service for one-two weeks and ask the users these simple questions
(obviously they could be better, POC ahead):What do you expect from PHP 5.5? (multiple choice)
- better security
- better stability
- better speed
- more language features
- other <type here>
- all of the above
Do you know what an opcode cache is?
- yes
- no
Would you be ok if PHP 5.5 will not ship in April 2013 but in August
2013 because we want to integrate an opcode cache, a functionality,
which once used could increase the speed of your applications by up to
50% or more*?
- yes
- no
- NOTE: the speed increase is not guaranteed to be the same for all
applications nor it is guaranteed.Would the fact that PHP 5.5 doesn't ship as originally planed, if the
mentioned integration happens, affect your view about PHP?
- yes
- no
What position do you have in your company?
- developer
- sysadmin
- devops
- manager
- other: <type here>
Are you in a position to influence the upgrade from your current PHP
version to PHP 5.5?
- yes
- no
Afaik every major framework has someone here, on the ML, then we have
Zend and we have some other libraries and so on here as well. Imagine
if all those people would link from their websites to the said poll. I
think it would be a small effort from them but the responses could at
least point out to what users actually want and help you in sorting
this out.If I offended anyone, which I'm almost sure I did, it was not my
intention, please forgive me.Thank you all for your hard work on PHP.
And I've forgot the most important question:
Would you skip PHP 5.4 migration if the opcode caching were to be
included by default in PHP 5.5?
- yes
- no
Best regards
Florin Patan
https://github.com/dlsniper
A huge, out of the box, speed bump for production machines.
For some applications PHP 5.4 was a huge speed bump out of the box . . .
A huge, out of the box, speed bump for production machines.
For some applications PHP 5.4 was a huge speed bump out of the box . . .
Would you run PHP against 10k+ req/s in production without opcode caching?
On how many machines without / with?
Florin Patan
https://github.com/dlsniper
Florin
Would you run PHP against 10k+ req/s in production without opcode caching?
On how many machines without / with?
I'm not sure about your stack, but every stack I've seen at that high of a
load is built very custom for the problem at hand. And it isn't typically
upgraded across minor versions (in fact, it's typically only upgraded for
security). At least that's my experience everywhere I've seen that big of a
farm... And when it is upgraded, it's usually a very coordinated effort
that takes a LOT of planning and has a lot of moving parts...
And to be fair, how many installs are there that get 10k req/s? A few
hundred? That's not the kind of system we should be targeting when
discussing a language feature/change. Sure it's sexy, but it represents
less than 1% of the install base of PHP (much less, prob on the order of
0.01%). So while I wouldn't write them off (far from it), justifying a
change because it matters to that scale is like justifying ejection seats
in cars because hitting a wall at 200mph on a race track can kill you...
Would you run PHP against 10k+ req/s in production without opcode caching?
On how many machines without / with?
This is getting a bit off-topic now, but all my work is geared towards
tools for users and system administrators in the LAN. We don't need an
op-code cache. We never get more than six unique users per day with
fairly low traffic from each. Does that mean we aren't important? I
sure hope not. . .
For us the new features are more helpful (we have plans for generators
already) because it makes certain iterators easier to build and
maintain.
I'm not sure about your stack, but every stack I've seen at that high of a
load is built very custom for the problem at hand. And it isn't typically
upgraded across minor versions (in fact, it's typically only upgraded for
security). At least that's my experience everywhere I've seen that big of a
farm... And when it is upgraded, it's usually a very coordinated effort that
takes a LOT of planning and has a lot of moving parts...And to be fair, how many installs are there that get 10k req/s? A few
hundred? That's not the kind of system we should be targeting when
discussing a language feature/change. Sure it's sexy, but it represents less
than 1% of the install base of PHP (much less, prob on the order of 0.01%).
So while I wouldn't write them off (far from it), justifying a change
because it matters to that scale is like justifying ejection seats in cars
because hitting a wall at 200mph on a race track can kill you...
Completely agreed. How many millions of tiny sites use PHP compared to
the few that serve up that kind of traffic?
I'm not saying performance isn't a concern; I am saying that your
concern is not typical of the average PHP developer.
Florin
Would you run PHP against 10k+ req/s in production without opcode caching?
On how many machines without / with?I'm not sure about your stack, but every stack I've seen at that high of a
load is built very custom for the problem at hand. And it isn't typically
upgraded across minor versions (in fact, it's typically only upgraded for
security). At least that's my experience everywhere I've seen that big of a
farm... And when it is upgraded, it's usually a very coordinated effort that
takes a LOT of planning and has a lot of moving parts...And to be fair, how many installs are there that get 10k req/s? A few
hundred? That's not the kind of system we should be targeting when
discussing a language feature/change. Sure it's sexy, but it represents less
than 1% of the install base of PHP (much less, prob on the order of 0.01%).
So while I wouldn't write them off (far from it), justifying a change
because it matters to that scale is like justifying ejection seats in cars
because hitting a wall at 200mph on a race track can kill you...
Anthony and Levi,
True but could we please get back to the whole mail and actually see
what the users want?
I would vote in the RFC if would be allowed to do so and I think I've
explained my perspective really well and the fact that I'm just one of
the hundred of thousands of PHP users.
I'm part of a very small group of people who have these problems, I
agree, but what I'm proposing should help out instead of just assuming
things.
The point is that this is yet another: we should this but that but
then and what if ... that could be solved by just asking the users and
taking that into account.
I could bet that people could care less about a stable release cycle
when things like this are at stake for certain versions.
Also, as a mention, I think that the current release every year target
is highly unrealistic unless you want to fragment the market the same
way that Google does it with Android. And look at the problems they
have with the adoption. If they can't serve as an example, I don't
know how can. Especially with PHP 5.4 experience. Are you willing to
bet that PHP 5.5 will do any better?
Best regards
Florin Patan
https://github.com/dlsniper
example, XDebug has no compatibility with ZendOptimizer+ right now (at
least that I could find, feel free to correct me if I'm wrong here).
I tested PHPUnit with both Xdebug and ZO+ enabled and got a correct
code coverage report. So at least that part of Xdebug is compatible
with ZO+.