> 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
> -Original Message-
> From: Rafael Dohms [mailto:lis...@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 Optim
On Fri, Mar 8, 2013 at 6:55 AM, Andi Gutmans wrote:
>
> 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, b
On Thu, Mar 7, 2013 at 10:00 PM, David Soria Parra wrote:
> 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, bu
On Fri, Mar 8, 2013 at 6:55 AM, Andi Gutmans wrote:
> 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 sp
>-Original Message-
>From: Anthony Ferrara [mailto:ircmax...@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
>distribution
>
On Mar 7, 2013, at 1:58 PM, Anthony Ferrara wrote:
> 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%
On Thu, Mar 7, 2013 at 9:58 PM, Anthony Ferrara wrote:
> 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 o
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 d
On 03/07/2013 10:33 PM, Philip Olson wrote:
>> 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
On 7 במרץ 2013, at 23:00, David Soria Parra wrote:
> On 2013-03-07, Rasmus Lerdorf wrote:
>> On 03/07/2013 09:01 AM, Anthony Ferrara wrote:
>>
>>> 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
On Mar 7, 2013, at 1:00 PM, David Soria Parra wrote:
> On 2013-03-07, Rasmus Lerdorf wrote:
>> On 03/07/2013 09:01 AM, Anthony Ferrara wrote:
>>
>>> 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
>>> classif
On 2013-03-07, Rasmus Lerdorf wrote:
> On 03/07/2013 09:01 AM, Anthony Ferrara wrote:
>
>> 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
>>
Yay!
Am 07.03.2013 um 17:48 schrieb Zeev Suraski :
> The voting period ended, and the option selected with 44 out of 70 votes
> was integrating Optimizer+ into PHP 5.5.0, even at the cost of a minor
> delay. An overwhelming majority (66 out of the 70 votes) was in favor of
> going with the integ
On Thu, Mar 7, 2013 at 6:18 PM, Zeev Suraski wrote:
> 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 goal
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
On 03/07/2013 09:01 AM, Anthony Ferrara wrote:
> 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 an
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 architectur
On Thu, Mar 7, 2013 at 5:46 PM, Pierre Joye wrote:
> On Thu, Mar 7, 2013 at 5:31 PM, Rasmus Lerdorf wrote:
> > On 03/07/2013 08:26 AM, Pierre Joye wrote:
> >
> >> 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 possib
On Thu, Mar 7, 2013 at 5:26 PM, Pierre Joye wrote:
> 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
--
PHP Internals -
...@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
On Thu, Mar 7, 2013 at 5:31 PM, Rasmus Lerdorf wrote:
> On 03/07/2013 08:26 AM, Pierre Joye wrote:
>
>> 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
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
On Thu, Mar 7, 2013 at 5:31 PM, Rasmus Lerdorf wrote:
> On 03/07/2013 08:26 AM, Pierre Joye wrote:
>
>> 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
On 03/07/2013 08:26 AM, Pierre Joye wrote:
> 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.
On Thu, Mar 7, 2013 at 5:06 PM, Zeev Suraski wrote:
> 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 peop
hi,
On Thu, Mar 7, 2013 at 5:01 PM, Nikita Popov wrote:
> "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
> shou
On Thu, Mar 7, 2013 at 5:06 PM, Zeev Suraski wrote:
> 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 p
] Integrating Zend Optimizer+ into the PHP
distribution
On Sun, Mar 3, 2013 at 10:23 AM, Rasmus Lerdorf wrote:
On 03/03/2013 12:43 AM, Pierre Joye wrote:
> On Sun, Mar 3, 2013 at 8:41 AM, Rasmus Lerdorf wrote:
>> The
>> first step towards integration is getting it in.
>
> Th
On Sun, Mar 3, 2013 at 10:23 AM, Rasmus Lerdorf wrote:
> On 03/03/2013 12:43 AM, Pierre Joye wrote:
> > On Sun, Mar 3, 2013 at 8:41 AM, Rasmus Lerdorf
> wrote:
> >> The
> >> first step towards integration is getting it in.
> >
> > That does not guarantee that further steps can be done, from a ti
> -Original Message-
> From: Lars Strojny [mailto:l...@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
>
>> 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 environmen
Hi Zeev,
Am 28.02.2013 um 21:16 schrieb Zeev Suraski :
> 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 pro
> -Original Message-
> From: Pierre Joye [mailto:pierre@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
> distribution
>
&g
On 03/03/2013 12:43 AM, Pierre Joye wrote:
> On Sun, Mar 3, 2013 at 8:41 AM, Rasmus Lerdorf 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 result
On Sun, Mar 3, 2013 at 8:41 AM, Rasmus Lerdorf wrote:
> 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
On 03/02/2013 11:25 PM, Pierre Joye wrote:
> On Sun, Mar 3, 2013 at 8:21 AM, Zeev Suraski wrote:
>>> 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 activ
On Sun, Mar 3, 2013 at 8:21 AM, Zeev Suraski wrote:
>> 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 Optim
> 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
--
PHP
hi Zeev,
On Sun, Mar 3, 2013 at 8:02 AM, Zeev Suraski wrote:
>
> 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
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
Th
On Thu, Feb 28, 2013 at 2:53 PM, Pierre Joye wrote:
> On Wed, Feb 27, 2013 at 5:12 PM, Zeev Suraski wrote:
>> 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, m
On 2013-02-27, Zeev Suraski wrote:
> On 27 2013, at 18:58, Anthony Ferrara wrote:
>
>> 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 sugges
On 02/28/2013 02:34 PM, Anthony Ferrara wrote:
> 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 tha
On Feb 28, 2013 9:16 PM, "Zeev Suraski" wrote:
>
> 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.
On Feb 28, 2013 8:16 PM, "Ilia Alshanetsky" wrote:
>
>
> 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 st
On 01/03/2013, at 9:22 AM, Jan Ehrhardt wrote:
> 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 cont
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 pul
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
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 b
On Thu, Feb 28, 2013 at 11:47 PM, Anthony Ferrara wrote:
> 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
On 28/02/2013 13:54, Ilia Alshanetsky wrote:
> 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 b
>> 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
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 vers
On Thu, Feb 28, 2013 at 11:37 PM, Levi Morrison wrote:
>> 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 withou
> 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 . . .
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> 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 w
On Thu, Feb 28, 2013 at 10:27 PM, Rasmus Lerdorf wrote:
> On 02/28/2013 11:34 AM, Anthony Ferrara wrote:
>> 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 compati
On 02/28/2013 12:49 PM, Stas Malyshev wrote:
> 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 pr
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 che
On 02/28/2013 11:34 AM, Anthony Ferrara wrote:
> 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 f
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 to
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
no
On Thu, 28 Feb 2013, Anthony Ferrara wrote:
> 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 th
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 coul
On Thu, Feb 28, 2013 at 8:13 PM, Stas Malyshev wrote:
> 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 ne
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 p
>> 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 wi
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 wi
>>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 stab
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 w
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
On Feb 28, 2013 7:56 PM, "Ilia Alshanetsky" wrote:
>
>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 cu
> 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 c
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
On 02/28/2013 10:37 AM, Nikita Popov wrote:
> On Thu, Feb 28, 2013 at 6:35 PM, Zeev Suraski wrote:
>
>> 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
On Thu, Feb 28, 2013 at 6:35 PM, Zeev Suraski wrote:
> 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
cod
On Thu, Feb 28, 2013 at 6:58 PM, Zeev Suraski wrote:
> 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 in
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 debat
On Thu, Feb 28, 2013 at 6:35 PM, Zeev Suraski wrote:
> 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
--
PHP Internals - PHP Runtime
No syntax changes, so regular majority as far as I can tell.
Sent from my mobile
On 28 בפבר 2013, at 19:33, Nikita Popov wrote:
On Wed, Feb 27, 2013 at 5:12 PM, Zeev Suraski wrote:
> Based on the overwhelming response, the vote is now open J
>
>
>
> https://wiki.php.net/rfc/optimizerplus
>
>
On Wed, Feb 27, 2013 at 5:12 PM, Zeev Suraski wrote:
> 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
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 reas
> -Original Message-
> From: Pierre Joye [mailto:pierre@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
hi Ilia,
On Thu, Feb 28, 2013 at 2:54 PM, Ilia Alshanetsky wrote:
> 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 wi
Jordi Boggiano in php.internals (Thu, 28 Feb 2013 15:33:06 +0100):
>On 28.02.2013 11:47, Frank Schenk wrote:
>> 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 cou
On 28.02.2013 11:47, Frank Schenk wrote:
> 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
Ilia,
On Thu, Feb 28, 2013 at 8:54 AM, Ilia Alshanetsky wrote:
> 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 wit
Zeev Suraski wrote:
>> -Original Message-
>> From: Pierre Joye [mailto:pierre@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]
hi Zeev,
On Thu, Feb 28, 2013 at 2:06 PM, Zeev Suraski wrote:
> 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.
> 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 u
On Thu, Feb 28, 2013 at 11:21 AM, Zeev Suraski wrote:
> 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 P
Zeev Suraski wrote:
-Original Message-
>From: Pierre Joye [mailto:pierre@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 Optimize
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 bu
> -Original Message-
> From: Pierre Joye [mailto:pierre@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
Den 28/02/2013 kl. 07.53 skrev Pierre Joye :
>
> 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 temptin
On Wed, Feb 27, 2013 at 5:12 PM, Zeev Suraski wrote:
> 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 P
Am 27.2.2013 um 22:01 schrieb Ferenc Kovacs :
> 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.
On Wed, Feb 27, 2013 at 10:19 PM, Rasmus Lerdorf wrote:
> On 02/27/2013 01:01 PM, Ferenc Kovacs wrote:
> 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. PH
On Wed, Feb 27, 2013 at 4:45 PM, Nikita Popov wrote:
>>
> 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 op
1 - 100 of 110 matches
Mail list logo
