Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66525
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c8G-dQHVgwbKL16kJmHjbJLMXai6bNS7TZjXT1OT+QBAQ@mail.gmail.com>
References: <435a322ccb14090d3bcf6bf8a110396d@mail.gmail.com>
	<CAEZPtU56QE=uMFcE+xe2vSzwCH_9KGFs33bJCySWpsx6Ed7k3w@mail.gmail.com>
	<CABBJUpds9XnOZC9gfDs8OHmoe6hTQosqe8qzmTtTX4Xg-JsT+Q@mail.gmail.com>
	<8944597477930141639@unknownmsgid>
	<CAEZPtU75+HZMcP+HUAEFGQ3R99g5_PsWJMd4OUkq+__s2CVc9w@mail.gmail.com>
	<1a0793107537dceb9cc67c616294ce76@mail.gmail.com>
	<CAEZPtU73==PG7QXT61LRZ0TNFUmtN1B5kBpXP1Cjvg2sZighGw@mail.gmail.com>
	<5132FE98.5050201@lerdorf.com>
	<CAEZPtU668P3YTn9g8CZbavb0nz-ui6NDKP0pCEb-7zZE+Q8-VA@mail.gmail.com>
	<513316A1.1050109@lerdorf.com>
	<CAF+90c8G-dQHVgwbKL16kJmHjbJLMXai6bNS7TZjXT1OT+QBAQ@mail.gmail.com>
Date: Thu, 7 Mar 2013 17:26:01 +0100
Message-ID: <CAEZPtU5WPhWh_yhcnFvTFdgPKsSez2DikEqrC2qthwHGUUbhzw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>, Zeev Suraski <zeev@zend.com>, Laruence <laruence@php.net>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Thu, Mar 7, 2013 at 5:01 PM, Nikita Popov <nikita.ppv@gmail.com> 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
> 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