# is_a() - again - a better fix - Thread: https://externals.io/message/55567 - Original archive: https://news-web.php.net/php.internals/55567 - Started by Alan Knowles on 2011-09-20T21:54:10+00:00 - Messages: 50 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/55567.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #55567 — Alan Knowles — 2011-09-20T21:54:10+00:00 URL: https://externals.io/message/55567#55567 Let's try and close this one. https://bugs.php.net/bug.php?id=55475 I've just added a patch that adds is_class_of(), which is identical to is_subclass_of, and has the new feature of supporting strings and using the autoloader. It then reverts `is_a()` back to the previous behavior, and clarifies the documentation. This solves the BC issues, and also solves potential security issues with existing code accidentally passing $url's to the autoloader, and gives anyone who needs this new behavior a solution. Let's at least try and respect the new release RFC, and our users who appreciate PHP's efforts over the years to try and maintain BC. (it's one of it's few advantages these days...) Regards Alan --- ## #55568 — Ferenc Kovacs — 2011-09-20T23:38:49+00:00 URL: https://externals.io/message/55567#55568 · In reply to: #55567 > Let's try and close this one. > > https://bugs.php.net/bug.php?id=55475 > > I've just added a patch that adds is_class_of(), which is identical to > is_subclass_of, and has the new feature of supporting strings and using the > autoloader. > > It then reverts `is_a()` back to the previous behavior, and clarifies the > documentation. > > This solves the BC issues, and also solves potential security issues with > existing code accidentally passing $url's to the autoloader, and gives > anyone who needs this new behavior a solution. > > Let's at least try and respect the new release RFC, and our users who > appreciate PHP's efforts over the years to try and maintain BC. (it's one of > it's few advantages these days...) > Hi Alan, As it was mentioned before, the main reason to not revert back to the old behavior is to not break BC once again (it shouldn't have happened in the first place, but we can't change that. :()- The security implications was never brought up though, but I think that it is plausible, that there are people out there without suhosin, having allow_url_include enabled, and using a vulnerable autoloader (the PSR-0 reference implementation is vulnerable for example), so maybe it is worth discussing. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #55569 — Alan Knowles — 2011-09-21T00:04:28+00:00 URL: https://externals.io/message/55567#55569 · In reply to: #55568 Ferenc, yes I know you are generally -1 on reverting this. Currently this bug has 20 votes all at 'this seriously affects me' I know Pierre and I are +1 for reverting this change I think Zeev and Stas where -1 for reverting I've already seen bugs on random packages (outside PEAR) reporting problems and thanking me for an explanation. Along with the security issue reported on one of the PEAR bugs. (not sure if it's in the wild or exploitable yet, but it is feasible) As I said before, BC break for practically nobody against those 20+ people is not a justification for me. I think we understand both sides of the arguments for this, I would appreciate if we could get a vote together if it is that contentious. Regards Alan > > > […] > Hi Alan, > > As it was mentioned before, the main reason to not revert back to the > old behavior is to not break BC once again (it shouldn't have happened > in the first place, but we can't change that. :()- > The security implications was never brought up though, but I think > that it is plausible, that there are people out there without suhosin, > having allow_url_include enabled, and using a vulnerable autoloader > (the PSR-0 reference implementation is vulnerable for example), so > maybe it is worth discussing. --- ## #55570 — Matthew Weier O'Phinney — 2011-09-21T13:57:35+00:00 URL: https://externals.io/message/55567#55570 · In reply to: #55567 > Let's try and close this one. > > https://bugs.php.net/bug.php?id=55475 > > I've just added a patch that adds is_class_of(), which is identical to > is_subclass_of, and has the new feature of supporting strings and using > the autoloader. is_class_of() has a very different semantic meaning (in natural language) than `is_subclass_of()` -- I know I wouldn't expect the behavior it exhibits by looking at the name. > It then reverts `is_a()` back to the previous behavior, and clarifies the > documentation. Reverting at this point adds a BC break on top of a BC break. Yes, the original perhaps should not have happened (and likely wouldn't have, if people had actually been testing the RCs...), but I'll argue again: the new behavior is more correct. Reverting at this point is simply going to cause more headaches: "package X works for PHP versions X.Y - 5.3.6, and from 5.3.9 to 5.3.last" -- what a nightmare! > This solves the BC issues, and also solves potential security issues > with existing code accidentally passing $url's to the autoloader, and > gives anyone who needs this new behavior a solution. I'd argue that this fix also highlights the need for autoloaders to test their arguments to see if they are getting something that looks like a class name. > Let's at least try and respect the new release RFC, and our users who > appreciate PHP's efforts over the years to try and maintain BC. (it's > one of it's few advantages these days...) To respect the release RFC, we shouldn't introduce a new BC break (breaking behavior with something already released). -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc --- ## #55571 — johannes@schlueters.de — 2011-09-21T14:24:54+00:00 URL: https://externals.io/message/55567#55571 · In reply to: #55570 > Reverting at this point adds a BC break on top of a BC break. Yes, the > original perhaps should not have happened (and likely wouldn't have, if > people had actually been testing the RCs...), but I'll argue again: the > new behavior is more correct. > > Reverting at this point is simply going to cause more headaches: > "package X works for PHP versions X.Y - 5.3.6, and from 5.3.9 to > 5.3.last" -- what a nightmare! 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. johannes --- ## #55572 — Pierre Joye — 2011-09-21T15:01:48+00:00 URL: https://externals.io/message/55567#55572 · In reply to: #55571 2011/9/21 Johannes Schlüter : > 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. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #55575 — Clint Byrum — 2011-09-21T18:31:44+00:00 URL: https://externals.io/message/55567#55575 · In reply to: #55572 Excerpts from Pierre Joye's message of Wed Sep 21 08:01:48 -0700 2011: > 2011/9/21 Johannes Schlüter : > > > […] > > 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. --- ## #55576 — Alan Knowles — 2011-09-21T23:41:51+00:00 URL: https://externals.io/message/55567#55576 · In reply to: #55575 To clarify * Code changed to work around this change will not break if it is reverted. Basically it is to add `is_object()` before any call to `is_a()` * If left as is, there is reasonable potential for remote exploits in many codebases. * This change is not really in the wild yet, as people do not upgrade that fast, and as mentioned distro's are avoiding upgrading due to the rather serious consequences. * This code affects anyone using the autoloader (PSR or other) with any existing codebase (for example Joomla will probably break if used with an autoloader) * The 'revert' BC break will only affect someone who a) uses undocumented behaviors which are only known about due to reading this list. b) has written code specifically targeting this controversial behavior in the last few weeks. * Nobody who has argued for keeping this change has made any commits or bug reports to any package (as far as I know) to help fix code affected by the change. * `is_a()` in it's previous usage was 'useful', and resulted in clear consise code. now practically every use of the code has to be prefixed with `is_object()`. This is wastefull and pointless, and more prone to errors. Saying that 'breaking BC again' should not be done is an utterly bogus argument. Please understand the issue properly before coming up with such a ridiculous comment. The point of 'not breaking BC' is to stop breaking existing code which has been running for years, not breaking code that has been created 10 minutes ago. Please be realistic here. The fix is trivial and it is either to a) add an extra argument to `is_a()` - 3rd argument true to autoload & use a string This I considered to be an unclear way of providing this feature.. b) create a new method is_class_of() - as the related method is `is_subclass_of()` instance_of() - might be a little better? class_compare() = 0(no) 1(same) 2(instanceof) Please note that the new behaviour is roughly equivalent to this. $cna = is_object($a) ? get_class($a) : $a; $cnb = is_object($b) ? get_class($b) : $b; if ($cna == $cnb) || is_subclass_of($a,$b) ) { } It's main usage is really to use with strings so this would work for anyone who needs the new feature. if ($a == $b) || is_subclass_of($a,$b) ) { } Please think of good names, and let's close this bug sensibly. Regards Alan > Excerpts from Pierre Joye's message of Wed Sep 21 08:01:48 -0700 2011: > > […] > 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. --- ## #55577 — Kalle Sommer Nielsen — 2011-09-22T00:41:14+00:00 URL: https://externals.io/message/55567#55577 · In reply to: #55575 Hi 2011/9/21 Clint Byrum : > 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. While I respect from a package maintainer standpoint the thought of reverting to the pre 5.3.8 behaviour would help the Ubuntu project, however, in the whole image it does not help the PHP project and it will without doubt create even more confusion than whats already been done by the change to `is_a()`. I've always been against changing behavior from de-facto PHP because people will quickly adapt to their distro behavior and wonder why their code breaks when they run it on their server thats using a de-facto version of PHP and the blame normally ends up at us. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #55580 — Ole Markus With — 2011-09-22T05:24:23+00:00 URL: https://externals.io/message/55567#55580 · In reply to: #55576 > > To clarify > > * Code changed to work around this change will not break if it is reverted. > Basically it is to add `is_object()` before any call to `is_a()` > > * If left as is, there is reasonable potential for remote exploits in > many codebases. > > * This change is not really in the wild yet, as people do not upgrade > that fast, and as mentioned distro's are avoiding upgrading due to the > rather serious consequences. > > * This code affects anyone using the autoloader (PSR or other) with any > existing codebase (for example Joomla will probably break if used with > an autoloader) > > * The 'revert' BC break will only affect someone who > a) uses undocumented behaviors which are only known about due to reading > this list. > b) has written code specifically targeting this controversial behavior > in the last few weeks. > > * Nobody who has argued for keeping this change has made any commits or > bug reports to any package (as far as I know) to help fix code affected > by the change. > > * `is_a()` in it's previous usage was 'useful', and resulted in clear > consise code. now practically every use of the code has to be prefixed > with `is_object()`. This is wastefull and pointless, and more prone to > errors. > > > Saying that 'breaking BC again' should not be done is an utterly bogus > argument. Please understand the issue properly before coming up with > such a ridiculous comment. The point of 'not breaking BC' is to stop > breaking existing code which has been running for years, not breaking > code that has been created 10 minutes ago. Please be realistic here. > Hi, Just for the record: For Gentoo, we actually did ship PHP 5.3.8, resulting in a little storm of users being very upset about us breaking their code. Especially since PEAR packages started breaking. Wearing my package maintainer hat and given that Alan's points above are true, I would very much like for is_a's behaviour to be reverted to pre-5.3.8 state as well. I also believe that reverting would cause less damage than keeping current behaviour. Cheers, Ole Markus --- ## #55581 — Rune Kaagaard — 2011-09-22T11:53:41+00:00 URL: https://externals.io/message/55567#55581 · In reply to: #55580 > Wearing my package maintainer hat and given that Alan's points above are > true, I would very much like for is_a's behaviour to be reverted to > pre-5.3.8 state as well. I also believe that reverting would cause less > damage than keeping current behaviour. The hugest of +1's! --- ## #55583 — Daniel Convissor — 2011-09-22T13:49:57+00:00 URL: https://externals.io/message/55567#55583 · In reply to: #55577 Hi Folks: > > While I respect from a package maintainer standpoint the thought of > reverting to the pre 5.3.8 behaviour would help the Ubuntu project, > however, in the whole image it does not help the PHP project Breaking PHP for untold thousands upon thousands of applications created over the past nine years is a FAR bigger problem for our image. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 --- ## #55584 — Jonathan Bond-Caron — 2011-09-22T14:02:21+00:00 URL: https://externals.io/message/55567#55584 · In reply to: #55570 > > > […] > > > To respect the release RFC, we shouldn't introduce a new BC break > (breaking behavior with something already released). > That's just a ridiculous statement, the release rfc should have been respected in the first place. Can you explain to me where in the RFC it explain that if "the new behavior is more correct" then a minor release can break BC? This whole story smells like bad PR, this is a new *feature* that breaks BC and not a bug fix. Either way, I don't have a strong opinion on reverting the change or not, but it should be *acknowledged* today that this "fix" did not belong in 5.3.8. If that's not done, then I have no hope for the future releases from PHP.net I'll look at package maintainers or companies with a more rigorous release process, it's that simple. --- ## #55585 — Kalle Sommer Nielsen — 2011-09-22T15:03:19+00:00 URL: https://externals.io/message/55567#55585 · In reply to: #55583 Hi 2011/9/22 Daniel Convissor : > 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. 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. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #55587 — Clint Byrum — 2011-09-22T17:27:43+00:00 URL: https://externals.io/message/55567#55587 · In reply to: #55585 Excerpts from Kalle Sommer Nielsen's message of Thu Sep 22 08:03:19 -0700 2011: > Hi > > 2011/9/22 Daniel Convissor : > > […] > > 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. --- ## #55588 — johannes@schlueters.de — 2011-09-22T17:43:02+00:00 URL: https://externals.io/message/55567#55588 · In reply to: #55587 > 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. This issue is not about packagers specifically. What we need is that more application and library developers test it. I think it is a shame that PEAR, a php.net project like PHP itself, breaks. This must not happen. I have no idea what to do though. We have a list of "primary testers" where I usually get one or two responses but most goes into the void. When talking to application maintainers they don't have the time or similar reasons and hope/trust that others will test enough. Maybe a good thing in all this is that it is wakening ... What else can we do? - More application tests? That's a nice idea but not knowing the applications it is relatively time consuming to analyze test failures in there (not to mention that many projects have a bad test coverage ..) that happen easily due to "unimportant" changes. johannes --- ## #55589 — Pierre Joye — 2011-09-22T18:02:29+00:00 URL: https://externals.io/message/55567#55589 · In reply to: #55588 2011/9/22 Johannes Schlüter : > > > […] > > This issue is not about packagers specifically. What we need is that > more application and library developers test it. I think it is a shame > that PEAR, a php.net project like PHP itself, breaks. This must not > happen. Well, the shame is more on our side as we did not revert this breakage when it was discovered (and it was before 5.3.8 was released). And we have hard discussions to even get an agreement about such changes being a BC break. I'm not willing to blame anyone but we are responsible here, 200%. > I have no idea what to do though. We have a list of "primary testers" > where I usually get one or two responses but most goes into the void. We do tests using apps in our labs and we report any breakage or bugs. We did it for this one as well. But the more we have the better :) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #55593 — Rasmus Lerdorf — 2011-09-22T22:43:47+00:00 URL: https://externals.io/message/55567#55593 · In reply to: #55589 I don't see the harm in reverting back to the previous behaviour in the 5.3 tree. It's not like it will break code that has been fixed to work with the new behaviour. -Rasmus --- ## #55594 — Alan Knowles — 2011-09-22T23:37:35+00:00 URL: https://externals.io/message/55567#55594 · In reply to: #55593 This patch adds an extra parameter 'allow_string' to is_a (default off) and is_subclass_of (default on) , https://bugs.php.net/patch-display.php?bug_id=55475&patch=Is_a_with_allow_string_argument_v3&revision=latest It also explains why their behaviour is different. This is a clean, no BC break, solution. let's move on and just fix this. Regards Alan > I don't see the harm in reverting back to the previous behaviour in the > 5.3 tree. It's not like it will break code that has been fixed to work > with the new behaviour. > > -Rasmus --- ## #55598 — Rasmus Lerdorf — 2011-09-23T10:06:28+00:00 URL: https://externals.io/message/55567#55598 · In reply to: #55594 > This patch adds an extra parameter 'allow_string' to is_a (default off) > and is_subclass_of (default on) , > > https://bugs.php.net/patch-display.php?bug_id=55475&patch=Is_a_with_allow_string_argument_v3&revision=latest > > > > It also explains why their behaviour is different. This is a clean, no > BC break, solution. let's move on and just fix this. Ok, executive decision made. Patch committed. We obviously screwed up in making this change in the 5_3 branch and since at least one distro has held off in pushing out newer 5.3 builds in order to not break every existing PEAR package, it is completely clear to me that this needed to be fixed in 5.3. So, a couple of ideas to address cases like this in the future. 1. Should we work up a basic PEAR test case that we can add to our tests? 2. Maybe we should think bigger and put more focus on having large PHP frameworks and apps test every RC. Currently we notify them of RCs and just hope someone will test and report back, but that obviously isn't working. We need a Daniel Brown-like approach to this. Someone who is really annoyingly persistent and will hunt down people to test RCs and keep a sign-off checklist of projects that have given a thumbs-up on an RC. Oh, and what do we do in 5.4? Philosophically I think Dmitry's original change was correct, but none of us realized all the code relying (arguably incorrectly) on the original behaviour. -Rasmus --- ## #55599 — Patrick ALLAERT — 2011-09-23T10:13:40+00:00 URL: https://externals.io/message/55567#55599 · In reply to: #55598 2011/9/23 Rasmus Lerdorf : > > > […] > > Ok, executive decision made. Patch committed. We obviously screwed up in > making this change in the 5_3 branch and since at least one distro has > held off in pushing out newer 5.3 builds in order to not break every > existing PEAR package, it is completely clear to me that this needed to > be fixed in 5.3. > > So, a couple of ideas to address cases like this in the future. > > 1. Should we work up a basic PEAR test case that we can add to our >   tests? > > 2. Maybe we should think bigger and put more focus on having large PHP >   frameworks and apps test every RC. Currently we notify them of RCs >   and just hope someone will test and report back, but that obviously >   isn't working. We need a Daniel Brown-like approach to this. Someone >   who is really annoyingly persistent and will hunt down people to >   test RCs and keep a sign-off checklist of projects that have given >   a thumbs-up on an RC. Solution 2: +1 Having a Jenkins instance which would run major framework testsuites against the different versions of PHP? > Oh, and what do we do in 5.4? Philosophically I think Dmitry's original > change was correct, but none of us realized all the code relying > (arguably incorrectly) on the original behaviour. > > -Rasmus --- ## #55600 — Pierre Joye — 2011-09-23T10:17:42+00:00 URL: https://externals.io/message/55567#55600 · In reply to: #55598 hi Rasmus, > 1. Should we work up a basic PEAR test case that we can add to our >   tests? > > 2. Maybe we should think bigger and put more focus on having large PHP >   frameworks and apps test every RC. Currently we notify them of RCs >   and just hope someone will test and report back, but that obviously >   isn't working. We need a Daniel Brown-like approach to this. Someone >   who is really annoyingly persistent and will hunt down people to >   test RCs and keep a sign-off checklist of projects that have given >   a thumbs-up on an RC. We do 2) already (while we are working on increasing the amount of apps and frameworks being tested), as I was asking to revert this patch between 5.3.7 and 5.3.8 back then pointing to our tests results and numerous reports. The problem was not in the QA but in the decision process. QA should have a kind of veto power in this case to avoid arguing and still have BC breaks landing in stable releases. > Oh, and what do we do in 5.4? Philosophically I think Dmitry's original > change was correct, but none of us realized all the code relying > (arguably incorrectly) on the original behaviour. It is not an easy decision, I would prefer to revert it there too as it will break BC in 5.4 as well, obviously. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #55601 — Rasmus Lerdorf — 2011-09-23T10:18:17+00:00 URL: https://externals.io/message/55567#55601 · In reply to: #55599 > 2011/9/23 Rasmus Lerdorf > > […] > > Solution 2: +1 > > Having a Jenkins instance which would run major framework testsuites > against the different versions of PHP? That would be cool, but a lot of work to maintain since every framework/app has different ways of testing and we'll want to test different versions. It seems like the best bet is to get the people who know the code best to maintain the tests. If we could get all of them to set up *and maintain* their stuff on the Jenkins instance it would be ideal, but that's probably dreaming in technicolor. -Rasmus --- ## #55602 — Rasmus Lerdorf — 2011-09-23T10:23:00+00:00 URL: https://externals.io/message/55567#55602 · In reply to: #55600 > We do 2) already (while we are working on increasing the amount of > apps and frameworks being tested), as I was asking to revert this > patch between 5.3.7 and 5.3.8 back then pointing to our tests results > and numerous reports. The problem was not in the QA but in the > decision process. QA should have a kind of veto power in this case to > avoid arguing and still have BC breaks landing in stable releases. Well, 5.3.7 - 5.3.8 wasn't really the problem. That release was rushed to fix my crypt screwup. This should have been caught in the 5.3.6 - 5.3.7 testing which lasted much longer than the short window to 5.3.8. -Rasmus --- ## #55603 — Pierre Joye — 2011-09-23T10:40:13+00:00 URL: https://externals.io/message/55567#55603 · In reply to: #55602 > > > > […] > > Well, 5.3.7 - 5.3.8 wasn't really the problem. That release was rushed > to fix my crypt screwup. This should have been caught in the 5.3.6 - > 5.3.7 testing which lasted much longer than the short window to 5.3.8. Right, also reported back then with the same success ;) Anyway, that's past, the BC break has been fixed and we are working to get these apps&frameworks tests result as part of our release process (symfony and doctrine are on the road, must see with zf if we can share resources as they do it anyway internally). Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- Next page: https://externals.io/message/55567.md?page=2