Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:66346 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 60631 invoked from network); 28 Feb 2013 19:15:43 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Feb 2013 19:15:43 -0000 Authentication-Results: pb1.pair.com smtp.mail=ircmaxell@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ircmaxell@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.181 as permitted sender) X-PHP-List-Original-Sender: ircmaxell@gmail.com X-Host-Fingerprint: 209.85.128.181 mail-ve0-f181.google.com Received: from [209.85.128.181] ([209.85.128.181:35108] helo=mail-ve0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3B/C6-25879-DDCAF215 for ; Thu, 28 Feb 2013 14:15:42 -0500 Received: by mail-ve0-f181.google.com with SMTP id d10so2153241vea.40 for ; Thu, 28 Feb 2013 11:15:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=q7qYlxWGotT7o2Om192Vn8g+cpL5xGl72/LgGSHG3VE=; b=ecFcclY/AY65LxZLMMYdv5v43+eOw1Mr4pG/AG31Y8dsGAFNQiS46MqkiPoZ+ZwMJl UAAfxvidIZuwth2F8GLd2gbzBBi9FAXPP7lGwPdqXdH5FY6fm+tzcemJZPrtsyyiKImW NVaIJmaAT65sGFJHhb4KDJknUn0Qbtpa9IXAO3622rB5Qd+m9aK7M7MaNV/JPnJz/D9s XqxlUHLzbD5ctHMcwb2f7h1yc2ZFzulcRcRwi+uJH42nEg4oA4i8GYiAPvS+A1B0YyRx MQda3iuz7KBuBklBDwsnduxTcpEzNY4XijKq+YCRBBsr9ID469+3KnuQYbMoHabLGScL gbTg== MIME-Version: 1.0 X-Received: by 10.58.23.169 with SMTP id n9mr2960262vef.58.1362078939367; Thu, 28 Feb 2013 11:15:39 -0800 (PST) Received: by 10.58.56.137 with HTTP; Thu, 28 Feb 2013 11:15:39 -0800 (PST) In-Reply-To: References: <435a322ccb14090d3bcf6bf8a110396d@mail.gmail.com> <512E7870.7010208@lerdorf.com> <0b8c20490dae9ecb9f9cd4a77cf47796@mail.gmail.com> Date: Thu, 28 Feb 2013 14:15:39 -0500 Message-ID: To: Ilia Alshanetsky Cc: Zeev Suraski , Pierre Joye , Ferenc Kovacs , Rasmus Lerdorf , PHP Developers Mailing List Content-Type: multipart/alternative; boundary=047d7b3398875688dd04d6cdb79b Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution From: ircmaxell@gmail.com (Anthony Ferrara) --047d7b3398875688dd04d6cdb79b Content-Type: text/plain; charset=ISO-8859-1 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: 1. 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. 2. 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. 3. 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 --047d7b3398875688dd04d6cdb79b--