On Sun, Mar 3, 2013 at 8:41 AM, Rasmus Lerdorf <ras...@lerdorf.com> 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 what is voted on is: "Integrate into 5.5, even if minor delay required" "Integrate into 5.5 only if it's not delayed, otherwise - 5.6" "Don’t integrate Optimizer+ to PHP" And what will actually happen if accepted is bundling&cleanup for 5.5, integration in 5.6 or later. That makes a rather huge difference, especially when it is about delaying 5.5 for a relatively unknown period. It is even more disturbing as the gain between that and having it in PECL for the meantime is very very low. A real integration (at least partially) may be done it during the beta phases but I very much doubt that it is feasible, stabilize it will likely take more time and beginning to do many changing to actually integrate o+ into core is way too risky during beta/RC phases. > The essential questions being asked by the RFC > are whether to delay 5.5 for it, no delay and wait until the next > version, or don't integrate at all the last of which implies > external-only distribution either through pecl or individual distros > simply packaging it from Github. Distros will distribute it as separate packages anyway, I do not really the point here. > And your beef about integration vs. bundling is rather nit-picky. No, it is not. Hence why I asked to have the roadmap (no date but a plan and actual actions listed) to have an informed vote. > The > first step towards integration is getting it in. That does not guarantee that further steps can be done, from a timely manner. > How much integration is > done will depend on what people come up with. I have a pull request in > for at least one level of integration that will allow it to save a stat > call by integrating more closely with the sapi layer to save that > initial stat if the sapi layer can pull it from the server layer. > > That > is more than mere bundling, but it should also be rather safe to do. That is done in APC already. Any extensions can use it, being in core or not. > What we do about earlier versions is a completely separate and mostly > unrelated issue. There is no real reason not to support those via pecl, > but that isn't what this RFC is about. And, like you say, there is > nothing stopping you or anybody else from making a pointer to it from pecl. I agree, it is a separate issue. However it does affect the decision about delaying 5.5 for it while everything do or add can be done via pecl. That's why I think everything should be part of the RFC so voters can take an informed decision based on the actual planed moves. The question about little 5.4 adoption because of the lack of opcode cache support does not apply to 5.5 and o+ as it already supports quite well, minus the remaining issues (see Matt's post earlier this week). But again, I am not trying to stop o+ being in core, but the contrary. Almost all our (my team colleagues) resources are on testing 5.5 and o+ (and APC too as a fallback). We also provided patches, use cases, etc. we discovered or implemented while testing 5.3/4/5 and o+ with our tests benchmarks. My only point is the actual gain to delay 5.5 even more without knowing when we can release it, shooting in the dark and the lack of PECL support for previous php versions (as in: won't reduce our work load because we will still have to support APC as a prio #1 for 5.3/4). Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
