On 03/03/2013 12:43 AM, Pierre Joye wrote: > On Sun, Mar 3, 2013 at 8:41 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: >> The >> first step towards integration is getting it in. > > That does not guarantee that further steps can be done, from a timely manner.
There is never any such guarantee and the current results of the vote clearly says that the majority of people are fine with a delayed 5.5 release. >> 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. So? It is not done in O+. The fact that APC is better integrated on this particular point doesn't invalidate this as a low-hanging fruit integration step for O+. And there are other such low-hanging fruits we are likely to find, test and deem stable enough to get into 5.5. >> 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. No, but you are certainly trying to delay it by suggesting that the current RFC needs to be rewritten and presumably voting restarted at which point you can shout louder about how much this is delaying the 5.5 release because you will have added a month of purely process time to the mix. The fact is that the current release managers support delaying the release on the chance that we can get a stable opcode cache into this release and there is decent majority support for this approach according to our own process however faulty it may be, so I would ask you to stand down and let us do our thing instead of getting in the way. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
