Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65372
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nEW_tHNObKcH3knin0-GPXakUiv1KoHYzjHiOJ1EB=wRg@mail.gmail.com>
References: <5d21b42656d49b4a71d9f808541bd745@mail.gmail.com>
	<252ADB1A-2660-4A45-B859-B92DA2C8B8D8@gmail.com>
	<CAAyV7nEW_tHNObKcH3knin0-GPXakUiv1KoHYzjHiOJ1EB=wRg@mail.gmail.com>
Date: Tue, 29 Jan 2013 13:14:13 +0000
Message-ID: <CAPwsocG=K5_2mV1Z-SWt=8WJ4AvVEqAz+J16dE7yNPCw-0cYKQ@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Tyler Sommer <sommertm@gmail.com>, Zeev Suraski <zeev@zend.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=14dae93410cb8de34b04d46d2b3b
Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
From: leight@gmail.com (Leigh)

--14dae93410cb8de34b04d46d2b3b
Content-Type: text/plain; charset=ISO-8859-1

On 29 January 2013 11:23, Anthony Ferrara <ircmaxell@gmail.com> wrote:

> Zeev,
>
> First off, very nice job on the RFC. I definitely like what's happening
> here.
>
> As far as delaying 5.5, I have mixed feelings. I think we should definitely
> consider the delay, but only in a time-boxed format. So if we say "1
> month", then if it's not ready to be committed in that month, it doesn't
> get in and we release 5.5 anyway.


Do you really think a month would be enough (we're talking implementation
and really thorough testing)?

We're fast approaching beta and the feature freeze, and this is by no means
a small feature (correct me if I am mistaken).

I think this would very much benefit from the time between releases to get
it really thoroughly integrated and tested. Far more eyes will see it, and
contribute to it in the time between 5.5 and 5.6 than if it is rushed for
5.5. Stability is king when it comes to adoption, and we really don't need
an edge case coming up at the last minute that gives people another reason
not to upgrade.

In addition, I would suggest putting in a feature freeze for everything
> except this feature as well. Not because we shouldn't have new features,
> but to prevent another "everyone wants this, so let's delay some more"
> feature 1 week before the timebox expires.
>

That would allow more focused testing and development on this specific
feature, but...


> Additionally, I don't like the precedent that this sets for future
> releases.


.. this.

There has already been a couple of discussions this week around "rule
bending" (voting / bc breaks). I think the release schedule is an important
one to stick to.

Is it possible to introduce O+ via PECL in the interim?

--14dae93410cb8de34b04d46d2b3b--