Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66302
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <512E7870.7010208@lerdorf.com>
References: <435a322ccb14090d3bcf6bf8a110396d@mail.gmail.com>
	<CAH-PCH5wD99wYKxBo0mKK2QQkJe_toQP+4pB1KXCVfqCYVAoJA@mail.gmail.com>
	<512E7870.7010208@lerdorf.com>
Date: Wed, 27 Feb 2013 22:30:01 +0100
Message-ID: <CAF+90c-DFtz1wAXFrymJUSn5ByRKjZfnNDd3PT-d4+nfEjxUcw@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Ferenc Kovacs <tyra3l@gmail.com>, Zeev Suraski <zeev@zend.com>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8f83a5c5123ae704d6bb7a04
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
From: nikita.ppv@gmail.com (Nikita Popov)

--e89a8f83a5c5123ae704d6bb7a04
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 27, 2013 at 10:19 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> On 02/27/2013 01:01 PM, Ferenc Kovacs wrote:
>
> > 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

--e89a8f83a5c5123ae704d6bb7a04--