[PHP-DEV] Re: confirm unsubscribe from internals@lists.php.net
Excerpts from internals-help's message of 2013-02-04 18:34:15 UTC: Hi! This is the ezmlm program. I'm managing the internals@lists.php.net mailing list. I'm working for my owner, who can be reached at internals-ow...@lists.php.net. To confirm that you would like cl...@fewbar.com removed from the internals mailing list, please send an empty reply to this address: internals-uc.1360002855.bilmpgalhkdhljjdphbb-clint=fewbar@lists.php.net Usually, this happens when you just hit the reply button. If this does not work, simply copy the address and paste it into the To: field of a new message. or click here: mailto:internals-uc.1360002855.bilmpgalhkdhljjdphbb-clint=fewbar@lists.php.net I haven't checked whether your address is currently on the mailing list. To see what address you used to subscribe, look at the messages you are receiving from the mailing list. Each message has your address hidden inside its return path; for example, m...@xdd.ff.com receives messages with return path: internals-return-number-mary=xdd.ff@lists.php.net. Some mail programs are broken and cannot handle long addresses. If you cannot reply to this request, instead send a message to internals-requ...@lists.php.net and put the entire address listed above into the Subject: line. --- Administrative commands for the internals list --- I can handle administrative requests automatically. Please do not send them to the list address! Instead, send your message to the correct command address: For help and a description of available commands, send a message to: internals-h...@lists.php.net To subscribe to the list, send a message to: internals-subscr...@lists.php.net To remove your address from the list, just send a message to the address in the ``List-Unsubscribe'' header of any list message. If you haven't changed addresses since subscribing, you can also send a message to: internals-unsubscr...@lists.php.net or for the digest to: internals-digest-unsubscr...@lists.php.net For addition or removal of addresses, I'll send a confirmation message to that address. When you receive it, simply reply to it to complete the transaction. If you need to get in touch with the human owner of this list, please send a message to: internals-ow...@lists.php.net Please include a FORWARDED list message with ALL HEADERS intact to make it easier to help you. --- Enclosed is a copy of the request I received. Return-Path: cl...@fewbar.com Received: (qmail 51607 invoked from network); 4 Feb 2013 18:34:14 - Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Feb 2013 18:34:14 - Return-Path: cl...@fewbar.com Authentication-Results: pb1.pair.com smtp.mail=cl...@fewbar.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=cl...@ubuntu.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fewbar.com from 65.98.207.245 cause and error) X-PHP-List-Original-Sender: cl...@fewbar.com X-Host-Fingerprint: 65.98.207.245 xencbyrum2.srihosting.com Received: from [65.98.207.245] ([65.98.207.245:59151] helo=xencbyrum2.srihosting.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2C/20-48414-558FF015 for internals-unsubscr...@lists.php.net; Mon, 04 Feb 2013 13:05:10 -0500 Received: from fewbar.com (cpe-76-94-217-164.socal.res.rr.com [76.94.217.164]) by xencbyrum2.srihosting.com (Postfix) with ESMTPSA id 2B28D338A2 for internals-unsubscr...@lists.php.net; Mon, 4 Feb 2013 10:05:07 -0800 (PST) Received: by fewbar.com (Postfix, from userid 1000) id C0138280566; Mon, 4 Feb 2013 10:05:04 -0800 (PST) Content-Type: text/plain; charset=UTF-8 From: Clint Byrum cl...@ubuntu.com To: internals-unsubscribe internals-unsubscr...@lists.php.net Subject: unsub Date: Mon, 04 Feb 2013 10:05:04 -0800 Message-Id: 1360001090-sup-5...@fewbar.com User-Agent: Sup/git Content-Transfer-Encoding: 8bit unsub -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4.0 rc6 and release
Excerpts from Johannes Schlüter's message of Mon Mar 26 16:09:20 -0700 2012: On Mon, 2012-03-26 at 12:00 -0700, Clint Byrum wrote: Our hands are tied, as the security team still does not feel comfortable shipping a PHP without Suhosin. Perhaps more can be done to convince the world that this is a safe thing to do now, but for now, we're taking the extremely conservative stance and shipping 5.3.10 with the Suhosin patch. Thanks everyone for chiming in, and especially thanks to Ondrej for pushing hard to get things tested and rebuilt. Thinking loud: One could also ship both. Yes this doubles the effort but gives users a choice :-) This simply won't happen in the main archive of Ubuntu. The whole point of having a version from the archive in an LTS is that it receives security updates for 5 years, regardless of upstream releasing fixes or not. If users want something unsupported, an effort can be made to setup a PPA: https://help.launchpad.net/Packaging/PPA In fact, Ondrej already went through the trouble of creating one for testing purposes: https://launchpad.net/~ondrej/+archive/php5 Ubuntu's paid (by Canonical) security team does not have the resources to support two versions of anything really. Often times two versions of something are provided (like python 2.6 and 2.7) during a transition like we see in PHP right now. However, one is generally in universe, which means it is only supported by the community. I think the lesson here is to get the necessary bits from Suhosin into PHP's core so that users can feel safe when using stock PHP, rather than needing to wait for the good and generous folks at the hardened PHP project to catch up. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4.0 rc6 and release
Excerpts from André Rømcke's message of Mon Mar 26 04:44:53 -0700 2012: On Fri, Jan 20, 2012 at 1:43 AM, Clint Byrum cl...@ubuntu.com wrote: Excerpts from Stas Malyshev's message of Thu Jan 19 16:08:28 -0800 2012: Hi! - According to this website there are still 94 test failures in 5.4 . Can you confirm all of them are minor problems? http://gcov.php.net/viewer.php?version=PHP_5_4 Most of them appear so, I'll go through them again to be sure and encourage others to do so too and raise red flags if somebody sees something bad there. Unfortunately, some tests are environment-dependent or otherwise have subtle dependencies or structure that make them work on one system and fail on another not because of the bug in PHP but because of the test itself. So, I have 0 fails on my Linux build but 6 fails on my Mac build. Other times some systems may not support some capability, use old version of the library, etc. and the test may not account for that. These tests should be skipped or marked as XFAIL on platforms they are known to fail on. Better to have no test than one that cannot be relied upon. All supported platforms should pass with 0 fails. These intentional skips should have open bugs that are documented in the test code so that a developer can find out why this test was disabled when trying to make a change covered by the test. I do not think it is practical to postpone release until we solve all of such problems, since this being volunteer-driven open-source project this means not having any release schedule at all. I prefer having the schedule even if that means we'd have to release with some known deficiencies. Its pretty bad actually. For all of PHP's success, this is something that continues to baffle me, and many others I have talked to who are charged with measuring quality and with patching systems in a timely manner. How better to document unreliable tests than to skip them with something like SKIPPED - known to fail on Mac. Its precisely this unreliability that forced me to take a conservative approach for Ubuntu 12.04 and recommend to the community that we ship 5.3.9 instead of 5.4.0. I would much rather have the new stuff in, but even if all the tests pass on the machine we run the test suite on, how can we be sure they won't fail in another time zone, or in some other strange configuration? Given that 12.04 beta2 will be out on Thursday, and the unit tests where fixed before shipping 5.4 (I naively assume), is this in or out? ref: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-php54 With beta freeze on march 22 I guess the mistake of bundeling 5.3 instead of 5.4 is already made, and we will have to live with that for the next 2 years for prod, and the next 7 months for dev. Our hands are tied, as the security team still does not feel comfortable shipping a PHP without Suhosin. Perhaps more can be done to convince the world that this is a safe thing to do now, but for now, we're taking the extremely conservative stance and shipping 5.3.10 with the Suhosin patch. Thanks everyone for chiming in, and especially thanks to Ondrej for pushing hard to get things tested and rebuilt. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
Excerpts from Sebastian Bergmann's message of Fri Mar 02 07:41:53 -0800 2012: On 03/02/2012 07:34 AM, Pierre Joye wrote: https://wiki.php.net/rfc/php53eol I discussed with Arne Blankerts and Stefan Priebsch over breakfast today and Stefan had an interesting idea: why not announce (now) that PHP 5.3 will go into EOL a year after PHP 5.5 comes out? * Now until PHP 5.5 comes out: bug and security fixes for PHP 5.3 * From the release of PHP 5.5: security fixes for PHP 5.3 for a year Ideally, PHP 5.5 would be out in a year from now, so it would come down to one year of bug and security fixes and one year of security fixes only. Makes sense to me. Just chiming in from the Ubuntu side of things. I think this is the most predictable, and helpful plan for users and for distributors. From the user standpoint, its quite useful to know where you stand for upgrade path. This should make conservative users comfortable with using 5.3 on existing projects until 5.5 enters RC phase, and then they can start evaluating their options to move to 5.5 or 5.4, as they know they'll have a whole year to evaluate 5.5. If you put a clock on 5.3, and 5.5 slips for legitimate reasons, then they'll be stuck with 5.4 only, and you may actually *miss* the opportunity to get people on the latest release. From a distribution standpoint, anything that lengthens the amount of time that PHP as a project fully supports a release makes our burden smaller, and gives our users a better chance at having stable software for the entire life of our LTS releases. Selfish, I know, but just stating the obvious fact. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
Excerpts from Kiall Mac Innes's message of Sat Feb 04 09:34:44 -0800 2012: Hi John, Ondřej (One of the Debian PHP maintainers) listed 5 or 6 reasons in the initial email in this thread. Honestly, I can't think of a good reason for Debian or anyone else to include 3rd party patches, whatever the patches purpose, in the default PHP packages. There are plenty of reasons to use a 3rd party patch. Operating systems are about supporting an well integrated system. If parts of that system are breaking integration or eating peoples data, the os integrator (Debian, RedHat, CentOS, Ubuntu, or even MS in some cases) must act to support its users. Staying as close as possible to upstream is absolutely critical for efficient operation of an Open Source operating system project like Debian and Ubuntu. However, above efficiency is security. If Suhosin mitigates security vulnerabilities, lowering the urgency with which fixes must be rushed out to users, then carrying it as a patch is, IMO, worth it. I have to sympathize with Ondrej, as I know how much effort he puts into maintaining the PHP packages in Debian. Its pretty demoralizing pushing a bug report upstream when you know its likely to get a response of please try without Suhosin. I think a more interesting discussion than the current one of who plays nice with whom and why I don't like your processes, is whether anyone other than Stefan would be willing to champion RFCs for all of the Suhosin patch to enter PHP's core, and be turned on by default. We've talked briefly in the Ubuntu project about this latest development, as we generally try to stay as close to Debian's packages as possible. Members of our security team have expressed reservations about following Ondrej's lead here. These are the people who have to work to get vulnerabilities patched in a timely manner across all supported releases of Ubuntu long after upstream has dropped support (currently that includes php 5.2.4 - 5.3.6). So, I think I could probably put myself in as somebody that would support an effort to bring Suhosin's mitigations into PHP core. I don't know that the greater Ubuntu roject could devote many man-hours to it, but perhaps I could write the RFC's and offer resources for testing. Since the patches are already written, it shouldn't be much code work, right? I think this would be something to discuss at the next Ubuntu Developer Summit. I don't believe we'll be disabling Suhosin in the precise release, scheduled to release as 12.04 in April. However, eliminating deltas from Debian and the greater community are always a topic that deserves discussion. I'd invite the PHP community to come and discuss this with us at this free event in Oakland, CA, USA, May 7 - 11. http://uds.ubuntu.com/ You can even request travel sponsorship here: http://summit.ubuntu.com/uds-q/sponsorship (let me know privately if you apply, and I can ask the organizers to give your sponsorship request a closer look) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4.0 rc6 and release
Excerpts from Stas Malyshev's message of Thu Jan 19 16:08:28 -0800 2012: Hi! - According to this website there are still 94 test failures in 5.4 . Can you confirm all of them are minor problems? http://gcov.php.net/viewer.php?version=PHP_5_4 Most of them appear so, I'll go through them again to be sure and encourage others to do so too and raise red flags if somebody sees something bad there. Unfortunately, some tests are environment-dependent or otherwise have subtle dependencies or structure that make them work on one system and fail on another not because of the bug in PHP but because of the test itself. So, I have 0 fails on my Linux build but 6 fails on my Mac build. Other times some systems may not support some capability, use old version of the library, etc. and the test may not account for that. These tests should be skipped or marked as XFAIL on platforms they are known to fail on. Better to have no test than one that cannot be relied upon. All supported platforms should pass with 0 fails. These intentional skips should have open bugs that are documented in the test code so that a developer can find out why this test was disabled when trying to make a change covered by the test. I do not think it is practical to postpone release until we solve all of such problems, since this being volunteer-driven open-source project this means not having any release schedule at all. I prefer having the schedule even if that means we'd have to release with some known deficiencies. Its pretty bad actually. For all of PHP's success, this is something that continues to baffle me, and many others I have talked to who are charged with measuring quality and with patching systems in a timely manner. How better to document unreliable tests than to skip them with something like SKIPPED - known to fail on Mac. Its precisely this unreliability that forced me to take a conservative approach for Ubuntu 12.04 and recommend to the community that we ship 5.3.9 instead of 5.4.0. I would much rather have the new stuff in, but even if all the tests pass on the machine we run the test suite on, how can we be sure they won't fail in another time zone, or in some other strange configuration? - There was this problem with 5.3.7 and the crypt() bug. Has there been some improvement in the process of handling test failures? For example mark expected failures as expected failures, and fix the tests or the code? Or are the failing tests stable since month and all of them are minor problems? Yes, there was work done on these. Most of those were fixed, but few still remain, especially across various environments (i.e. test may be fine on some but not others). I of course am all for fixing that further and welcome any help on that. - There have been 319 unique failed tests in RC5, reported by user tests. Is someone looking into them and trying to classify and/or fix them? http://qa.php.net/reports/ Non-reproducible failures usually mean the problem is with the test itself, or with the difference of expectations in the test and local environment, not with PHP. It may still be PHP problem, of course, so the person running the test should check it out and submit a bug if appropriate and if it's bad enough, also send a message to this list. All in all the number of test failures still feels very high, I would be interested in your opinion. Is this normal for big projects like this? I do think it should be reduced, however if the choice is between waiting forever and have release with some bugs, I think it is practical to choose the latter. Of course, if we discover a major problem that makes PHP unusable or seriously impacts many PHP users, it will be dealt with immediately, and had been so in the past, but otherwise we have to work within the realities of a big project with limited resources and realize that while we strive for 0 bugs in every release, it may never be possible. All software will have bugs. The test suite, however, should reflect the bits of code that you know work reliably... not the bits of code you know work most of the time. The fact that its all being running regularly is a fantastic improvement. I'd like to see a commitment to getting 100% pass/xfail/skip for every release/tested environment in future releases though. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.9 and is_a changes
Excerpts from Clint Byrum's message of Sun Oct 23 18:36:04 -0400 2011: So, I've registered a blueprint for UDS here: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-php54 There's no guarantee we will be able to fit it in, so make sure to subscribe to it if you are interested in this topic. If any of you are interested in joining us virtually (or physically!) You can go here: https://launchpad.net/sprints/uds-p And register, then find it on the schedule at http://summit.ubuntu.com If you register for UDS-P with your available times, and subscribe yourself as essential for the blueprint, then the scheduler for the summit will make a best effort to put the session during the times you are available. Thanks to those of you who subscribed or attended virtually. We decided to defer this decision to January based on the status of 5.4.0. Its most likely we'll follow Debian's lead, so if Debian testing has 5.4.0 at that time, and we get a sufficient amount of testing, we will go ahead and update to 5.4.0. We'll also be setting up a PPA with 5.4.0 and all extensions compiled against it so users can try out their applications on precise with 5.4.0 before we actually do the transition. Please watch the blueprint if you are interested: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-php54 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-maint] [PHP-DEV] PHP 5.3.9 and is_a changes
Excerpts from devis's message of Mon Oct 24 15:18:14 -0700 2011: Hi, I have always disliked the lack of modern packages on Debian/Ubuntu distros, I feel like minor are misused as major versions, with an exaggerated fear to upgrade. It's like building web sites for IE6 because people are not allowed to upgrade to IE9, very frustrating for developers and hard to explain to stakeholders. (OT: so I welcomed Chrome/FF choice to bump major versions very frequently). Why can Ubuntu only support 5.3.x and not simply 5.x ? As far as I can see BC will be guaranteed, PHP maintainers are really committed to it, and only a new major version would be so problematic as many suggest. As a user, I would really encourage to include the latest stable 5.x and provide to the community all the available 5.x upgrade during the next 5 years (5.4, 5.5 etc). Those 105 php apps should be maintained or removed, not used as an excuse to slow down the community. devis, Firefox and Chrome are leaf packages. They can bump versions and they only affect one package, themselves. This allows testing to be simple and definitive. PHP supports not only the 105 apps in the Ubuntu archive, but thousands upon thousands of PHP applications which people write to run on top of Ubuntu. By freezing around a single version, and emphatically reviewing each update to ensure it does not introduce any changes in behavior (even positive changes!) without a clear justification (fixing a critical bug for instance), users can be assured that the app they write for any given release of Ubuntu will continue to function for the life of that release. We actually do have a micro release exception process which we have in place for a few upstreams: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions PHP5 isn't actually that far off from the requirements there, just need to enable the regression tests in the build and have them all pass. As I understand it, PHP 5.4 will have that, so one more positive for that. Note that we also have the ubuntu-backports project which can be used to obtain newer versions in the older release. There is a requirement, however, that all dependent packages are smoke tested with each backport, so somebody would have to automate testing all of the PHP applications in Ubuntu before backports was a viable option. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.9 and is_a changes
Excerpts from Hannes Magnusson's message of Sat Oct 22 04:03:50 -0700 2011: On Fri, Oct 21, 2011 at 22:52, Clint Byrum cl...@ubuntu.com wrote: Hi everyone. I'm trying to plan things for Ubuntu's upcoming 12.04 LTS release. LTS stands for Long Term Support, and it will be supported by Canonical for 5 years. Because of this, I really want to ship a version Wouldn't you rather want to include 5.4? 5.3 will no longer be supported by us shortly after your release.. So for the next 5 years you will be including something that is already unmaintained? I appreciate the sentiments of all who have weighed in on this, and I do want to make sure that we are paying attention to the greater PHP community's needs, not just Ubuntu's users. Shipping really old PHP versions is definitely not what we want to do. However, we do need to be able to support the release with updates. While 5.4 would probably mean more of those updates would be simple cherry picks from 5.4, it also means there would likely be a lot more of them, since 5.4.0 will undoubtedly be a more aggressive release than 5.3.9, and like any .0 release, it just won't have the exposure that 5.3.x has had. Also, we have 105 PHP applications in Ubuntu, 2 of which are in our main component (ganglia and nagios), which means they are supported by our security team and developers for the entire lifecycle of a release. Its not likely that we would be able to test all 105 of them with PHP 5.4 before the release date, which may mean some of them will be quite broken, and also require stable release updates to fix. Now, all of that said, I would love to have 5.4 as the version in 12.04. Since 103 of the 105 apps are community supported, that means we'd need a large community effort to make sure this is doable. Here's what would need to happen for 12.04 to ship with 5.4 instead of 5.3: 1) PHP needs to make a commitment to release very soon. Beta is fine for the first month or so of the cycle, but not more. 2) App developers need to commit to testing their apps on the dev release of Ubuntu. If people are interested, I'd be happy to set up a jenkins instance somewhere and give people write access to a bzr/svn/git tree of tests to run daily on the dev release. 3) We would need buy in from the rest of the server interested folks and the Ubuntu security team. The right time to discuss that is at the Ubuntu Developer Summit, which is coming up in Orlando, FL, US, just a week from Monday (starts Oct 31). 4) We need it *at least* in Debian experimental, preferrably in Debian unstable. I have not discussed this at all with the Debian PHP maintainers, so this is a big unknown. I've cc'd them for their comment. I do see that 5.4.0 beta is in experimental as of yesterday, so I suspect this will happen naturally. So, I've registered a blueprint for UDS here: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-php54 There's no guarantee we will be able to fit it in, so make sure to subscribe to it if you are interested in this topic. If any of you are interested in joining us virtually (or physically!) You can go here: https://launchpad.net/sprints/uds-p And register, then find it on the schedule at http://summit.ubuntu.com If you register for UDS-P with your available times, and subscribe yourself as essential for the blueprint, then the scheduler for the summit will make a best effort to put the session during the times you are available. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3.9 and is_a changes
Hi everyone. I'm trying to plan things for Ubuntu's upcoming 12.04 LTS release. LTS stands for Long Term Support, and it will be supported by Canonical for 5 years. Because of this, I really want to ship a version of PHP that has an is_a() behavior that will be consistent with any future 5.3.x releases. We just recently updated to 5.3.8 in the release that will become 12.04 (precise pangolin) somewhat accidentally by following Debian's lead. We may need to cherry pick the is_a() reversion into this release, but what I'd rather do is just ship 5.3.9. The release date is April 26 2012, can anyone tell me if 5.3.9 is expected by then? Ideally it would be much much earlier than that so users have time to test. And also can somebody please confirm for me that 5.3.9 will have the is_a() behavior that one would expect all future versions of PHP 5.3 to have? Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: is_a() - again - a better fix
Excerpts from Kalle Sommer Nielsen's message of Thu Sep 22 08:03:19 -0700 2011: Hi 2011/9/22 Daniel Convissor dani...@analysisandsolutions.com: Breaking PHP for untold thousands upon thousands of applications created over the past nine years is a FAR bigger problem for our image. While don't like the change due the break in a stable branch which I also wrote about in the bug report. Then I don't see why this was not caught in one of the RC packages sent out to confirm there was no behavior changes, but we got no feedback on it and went ahead. While it is unfortunate and it should have been reverted in the patch level sort of release, it wasn't. So I see that 5.3.7 was in RC from 6/16 until it was released August 18. In all that time, nobody caught this behavior problem, because nobody seems to have tested the RC's with code that was doing the wrong thing. We're happy to get out ahead (in fact, I should say, Ondrej Sury from Debian is always far more active in this effort than any of us in Ubuntu are, we pretty much stand on his shoulders) and test RC's, but other than running the test suite, much like Ondrej did, I don't know that there would be much we can do in 2 months. We can't very well throw this new version into our dev release of Ubuntu and expect serious users to try it out. We are on a time based release in Ubuntu also, so we can't in good conscience go to RCX without some assurance that the final will a) be out before our release, and b) won't change behaviors from earlier RC's. So I'm not sure what you would expect from distros, but please share and we'll setup automated tests, call for our users to test, whatever it takes to avoid this type of situation. Actually it is 7 years theoretically because we don't support PHP4, while I know that the change was at our end, that still doesn't justify a change of behavior in a package. It is not like we change the inner workings of PHP when packaging the Windows port. What needs to be done here, is to simply move on, endless rage is not solving anything, nor is it to have everyone go their way. 5.4 is coming a long greatly with the improved test cases, and I think to isolate such issues then the package maintainers should test the RC's with either popular packages in their system or related, so issues like this is caught in that process. There's no rage at all here. I think it makes sense to make a promise to users that behaviors will not change at all for any minor release series. 5.3.8 should work exactly like 5.3.0, except where the existing behavior was just too disruptive or dangerous. To me, the new behavior has been cited as more dangerous than the old one, so I'd think that people would want it to be reverted. But I would agree that quibbling over it endlessly is not productive. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: is_a() - again - a better fix
Excerpts from Pierre Joye's message of Wed Sep 21 08:01:48 -0700 2011: 2011/9/21 Johannes Schlüter johan...@schlueters.de: Exactly. (while I, at this time, won't argue which behavior is more correct) changing this in the first place was wrong. Changing it back is wrong again. We have two versions out with this change. These releases reach distributions, reach hosting companies, reach developer machines, ... changing the behavior again causes more trouble. With a proper heads up before 5.3.8 we might probably have reverted it there. I agree and I seriously hope that we will stop to do such things from now on and apply the RFC to 5.3 as well. Just to give some perspective on this, we specifically did not ship php 5.3.8 in Ubuntu 11.10 (in beta right now) because of this confusion. This is in spite of the fact that it would have closed many bugs, and reduced some of the burden on our security team since they are charged with back-porting all security fixes to whatever we ship. I was kind of hoping it would be rolled back rapidly in another release. From a distribution standpoint, the change in 5.3.8 is a nightmare and will require us to either ship with lots of bugs in the dependent packages, or lots of patches and delta from upstream. Reverting back to the pre 5.3.8 behavior would allow us to ship the new version and move forward with future versions without worry. One question.. if things have been adapted for 5.3.8 .. will they be negatively affected by a rollback to pre 5.3.8 behavior? If not, I'd wonder why there would be any resistance at all to doing this, as it seems more important that 5.3 is consistent from early versions to the latest than it is that one version had a serious problem. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Change Request: Make PDO default to not emulate prepared statements for MySQL
Excerpts from Rasmus Lerdorf's message of Sat Apr 30 10:53:30 -0700 2011: On 04/30/2011 10:36 AM, Stas Malyshev wrote: Hi! Do you realize why we did this in the first place? The common versions of MySQL in use out there are not very clever when it comes to the native prepared statement handling. First, there is no prepared statement cache, so there is no benefit to doing them natively, but Since 5.1.17 there is: http://dev.mysql.com/doc/refman/5.1/en/query-cache-operation.html And 5.1.17 is 4 years old already. People upgrade their databases even slower than they upgrade their PHP. That said, MySQL 5.0 is only in Extended Support[1] (read: security only) from Oracle, and will likely be deprecated to full EOL at some point in the near future. I think its fair to say that if something is a massive problem for a version that the authors don't even support, its probably ok to leave those users behind with defaults, as long as you give them a way to turn it off. So maybe this could be considered blocked only by 5.0's EOL. -- [1] http://www.mysql.com/support/eol-notice.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE : Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
On Wed, 2010-12-08 at 01:11 +, Gustavo Lopes wrote: On Wed, 08 Dec 2010 00:45:56 -, Tjerk Meesters tjerk.meest...@gmail.com wrote: Don't have much knowledge about the internal workings of the engine, but I'm wondering if it's possible to apply lazy loading to the $_POST variable, so that processing only happens if and when it's requested. That way you wouldn't need the ini setting. In most cases, processing (=parsing) of the POST data already only occurs when $_POST is requested; however, previously the data was already entirely copied to two or three memory locations. If you mean making it so that the data is only *read and processed* when $_POST is requested, I suppose that would be possible, but I think it would require significant code/architectural changes to PHP and to the sapis. It would also raise other problems, including backwards compatibility breaks, if we wanted the change to bring any benefit. For instance, current scripts can, in POST requests, read any number of times from php://input or $HTTP_RAW_POST_DATA (to simplify, let's say we even let go $HTTP_RAW_POST_DATA). For this to be possible, you would have to have the data in memory because you're reading from php://input the first time, you can't know if it will be read a second time, so you either break BC or keep everything in memory just in case there's a second read -- and then you're where you started. This example would be solved if during the lazy load you change the php://input stream to point at the memory location that you read it into. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE : Re: [PHP-DEV] [PATCH] Add option to disable POST data processing
On Wed, 2010-12-08 at 18:49 +, Gustavo Lopes wrote: On Wed, 08 Dec 2010 15:10:30 -, Clint Byrum cl...@ubuntu.com wrote: On Wed, 2010-12-08 at 01:11 +, Gustavo Lopes wrote: For instance, current scripts can, in POST requests, read any number of times from php://input or $HTTP_RAW_POST_DATA (to simplify, let's say we even let go $HTTP_RAW_POST_DATA). For this to be possible, you would have to have the data in memory because you're reading from php://input the first time, you can't know if it will be read a second time, so you either break BC or keep everything in memory just in case there's a second read -- and then you're where you started. This example would be solved if during the lazy load you change the php://input stream to point at the memory location that you read it into. I'm sorry, this doesn't make any sense. The memory location you read into? Who says you read the post data *into* something, much less a memory location? Sorry, to be more clear: A lazy load on access to $_POST or $HTTP_RAW_POST_DATA would have to read the POST data from the SAPI. At that point, the SAPI can keep the buffer it allocates to read that data as a memory stream, and change its notion of php://input to refer to that stream. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Sat, 2010-11-27 at 16:26 +, Lester Caine wrote: At the end of the day however it probably has nothing to do with which DVCS is used for master copies. The interoperability now available does mean that we can safely ignore any 'choice' and simply use our own preference locally :) It will be the management of processes which are the main problem, something that is still outstanding anyway currently ... Agreed that most of them are pretty interoperable at this point. ** DISCLAIMER: I am an employee of Canonical, owners of Launchpad ** May I suggest bzr+launchpad as another alternative. MySQL has successfully migrated, and it would offer some real benefits to the process management. * Release and Milestone Management for bugs and specs (Blueprints) * Blueprints tied to milestones/releases (Blueprints == RFC's) * Powerful web based merge proposal management. * Branch aware bug management (bzr commit --fixes lp:1234567 bzr push automatically attaches the branch to the bug) I've not used git or hg much at all, but bzr has always satisfied my needs for DVCS, and has recently gotten much faster and more space efficient than it was in the past. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4 alpha
On Mon, 2010-11-01 at 15:32 -0700, Derick Rethans wrote: Hi, we're a bit further along now; and with the typehinting resolved (http://thread.gmane.org/gmane.comp.php.devel/62298/focus=62858) I want to start started with PHP 5.4 with the first alpha on Wednesday, November 24th. There are a few things that need sorting out and/or clarification: - Annotations - Lemon rewrite - APC in trunk I don't think we can sort out the latter two before the alpha/branching. For Lemon because the rewrite apparently makes things slower; and for APC because it's still quite a lot of work to make it even work with trunk. For each of those three points, I will reply to this mail with a summary, and some suggestions. It strikes me that PHP is a bit bound up by conflicting interests, as any good language should expect to be as it matures and grows beyond its original focus. I wonder if a more structured release cadence would improve the experience for developers. One of Ubuntu's strengths as a development platform is that there is a clear date that, should a feature be specified and agreed upon by, it will be included in the release. The criteria for each of these freezes are well published, and so plans can be made based on how close to these criteria any one feature is. As an example of this, the RFC for annotations has been well discussed, but no decision about whether or not a syntax element is necessary or a good idea has been made. Its status as a blocker for 5.4 would only be considered until a certain point, a feature definition freeze, and then after that, it is rejected completely for the release. This does not mean work stops on it, but rather the effort now has a new timeline. Likewise if it is defined enough to be included, it may still fall out if the implementation falls behind. The alternative, of trying to make everything fit together, seems like it will just lead to things taking much, much longer. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Sessions lock - not using memcached?
On Sep 26, 2010, at 1:10 AM, ROZE Samuel wrote: Hello, I'm working with sessions in my PHP applications. My pages can take long time to be executed (~500ms) and I've simultaneous requests for the same session (Ajax requests). My problem is that I close sessions at the end of my PHP script, so my sessions files are locked for half a second. So, simultaneous requests (for the same session) can't be executed... simultaneously! My question is if I use memcached to store sessions, will my sessions be locked or can I access to them in the same time? If there aren't it should solve my problem. A second question is performances: is memcached sessions faster the PHP default sessions? I think yes because it doesn't make disk I/O..? No, the default memcache session handler has no locking. But that presents you with a new problem of a race condition. This is why you shouldn't keep any actual data in sessions: R1:[initial request start, session is read and has X=1] A1:[ajax request 1 reads session, X=1] A2:[user clicks add 1 to my shopping cart, X = X+1 = 2] A2:[displays shopping cart with X == 2] A2:[faster than A1, session over, write session with X = 2] A1:[session over, write session with X = 1] DOH! There has to be some kind of locking on data between read/write to maintain consistency. One way you can get around this is by *not* using the session for mutable data, and just using it to store a key to the data in your backend, and then only writing when you must. The above becomes R1:[initial request start, session is read and has shopping cart SID=1] A1:[ajax request 1 reads session, SID=1] A2:[user clicks add 1 to my shopping cart, UPDATE carts SET X = X + 1 WHERE SID = 1] A2:[displays shopping cart with X == 2] A2:[faster than A1, session over, write session with SID=1] A1:[session over, write session with SID=1] Also, the memcache session handler can be dangerous in that it might choose to delete your session before expiration if memcached fills up, so be aware of this. Good luck! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Annoucing PHP 5.4 Alpha 1
On Aug 10, 2010, at 10:42 PM, Michael Wallner wrote: On 08/11/2010 12:03 AM, Kalle Sommer Nielsen wrote: Greetings hackers I spoke with Derick today, and we both agreed on releasing an alpha of PHP 5.4 to show the public what we have been working since 5.3. We are going to release an alpha at september 2nd, which meaning packaging is going to happen on 1st September (SVN tag, Windows binaries, etc.) This is not going to be PHP as we know it. It's something hybrid, something anomalistic. I won't officially support this BS, no matter what. Right! Thats sort of the point. BS meaning Beta Stuff, right? ;) The comment was made that there is a desire to follow the Ubuntu release model with periodic Long Term Support releases, and interim releases to showcase and vet big language changes. So, support the LTS versions of PHP, and let developers try out new features in a hassle free manner with these interim releases. It sure beats the current model where a giant splash is made every few years requiring refactoring of code, testing, and deployment without ever having been able to test things out without running the nightly builds of the trunk, and without having any idea as to when those builds will start to look like the next stable release. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] IMAP patches from kolab -- can we get these merged?
Yesterday I was talking with one of my Colleagues about the Kolab project's use of some of the newer features of IMAP, notably, annotations and myrights. It turns out Kolab ships a patched PHP to do this properly, and they've been maintaining these patches for quite some time. In fact, they're up to date with 5.3.2, as seen here: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/php/patches/php-5.3.2/ Now, the myrights patch was actually submitted as a feature request here: http://bugs.php.net/bug.php?id=43948 Which, it seems, has sat unattended for the past 2.5 years. I'm not sure if the annotations patch has ever been submitted. I'd like to get these patches into mainstream PHP so that we don't have to ship some weird patched kolab-only IMAP module in Debian and Ubuntu. In fact, I'm quite opposed to doing that at all, but this means having a broken Kolab in Debian and Ubuntu (as I understand it, Horde uses the myrights patch too). I'm just wondering what it will take to get these patches merged into PHP. Do we need to update documentation as well? Thanks very much for your time! -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
