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
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
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
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.
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
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
2011/9/21 Johannes Schlüter johannes@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.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Excerpts from Pierre Joye's message of Wed Sep 21 08:01:48 -0700 2011:
2011/9/21 Johannes Schlüter johannes@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.
To clarify
-
Code changed to work around this change will not break if it is
reverted.
Basically it is to addis_object()before any call tois_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
withis_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:
2011/9/21 Johannes Schlüterjohannes@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.
To clarify
Code changed to work around this change will not break if it is reverted.
Basically it is to addis_object()before any call tois_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
withis_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
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!
Hi
2011/9/21 Clint Byrum clint@ubuntu.com:
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
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
Hi
2011/9/22 Daniel Convissor danielc@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.
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
Excerpts from Kalle Sommer Nielsen's message of Thu Sep 22 08:03:19 -0700 2011:
Hi
2011/9/22 Daniel Convissor danielc@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.
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
2011/9/22 Johannes Schlüter johannes@schlueters.de:
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.
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
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
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
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
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
https://bugs.php.net/patch-display.php?bug_id=55475&patch=Is_a_with_allow_string_argument_v3&revision=latestIt 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.
-
Should we work up a basic PEAR test case that we can add to our
tests? -
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
2011/9/23 Rasmus Lerdorf rasmus@lerdorf.com:
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
https://bugs.php.net/patch-display.php?bug_id=55475&patch=Is_a_with_allow_string_argument_v3&revision=latestIt 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.
Should we work up a basic PEAR test case that we can add to our
tests?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
2011/9/23 Rasmus Lerdorf rasmus@lerdorf.com
- 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?
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
2011/9/23 Rasmus Lerdorf rasmus@lerdorf.com:
2011/9/23 Rasmus Lerdorf rasmus@lerdorf.com
- 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?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.
Most serious PHP libraries/frameworks have a CI server. But they are
mainly setup to discover when someone breaks something rather than
testing various releases of PHP (and certainly not RC ones).
Open up an Jenkins instance with some guidelines on how to add a new
project which will be automatically launched with different releases
of PHP and I am sure project leaders will be glad to setup their
project(s) to know if their libraries/framework break with a specific
release of PHP.
Note that the libraries/frameworks wouldn't be supposed to be updated
against their VCS.
Ideally key releases of those libs/frameworks would be setup.
Davide Mendolia (in CC) has started such a project in the past.
Patrick
2011/9/23 Rasmus Lerdorf rasmus@lerdorf.com
- 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?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.
I've made the decision that my team will test against RCs as soon as
they are out (and we're going to be trying to do each beta as well). If
we run into issues, we'll of course report back here.
That said, I think it would be good to have a notification system
whereby framework leads are all pinged on new betas and RCs, and a wiki
page where they can indicate that they've run tests (and whether or not
they had issues). That way, you could have a targetted nag list -- "Hey,
I don't see an update from you -- RUN THE TESTS!", and a deadline
whereby if they haven't run them, they accept the consequences. :)
I could also see this being an interesting peer-pressure move -- "First
to test!", "We tested last week; how come you haven't?", etc.
--
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
That said, I think it would be good to have a notification system
whereby framework leads are all pinged on new betas and RCs, and a wiki
Something could probably monitor
http://svn.php.net/repository/php/php-src/tags/ for changes and alert
people then. There would certainly be false positives along the way, but
it should work fine most of the time.
Given sufficient interest I can look into this.
- Martin
2011/9/23 Rasmus Lerdorf rasmus@lerdorf.com
- 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?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.I've made the decision that my team will test against RCs as soon as
they are out (and we're going to be trying to do each beta as well). If
we run into issues, we'll of course report back here.
Good are also "success" reports so we know tests were run and succeeded.
That said, I think it would be good to have a notification system
whereby framework leads are all pinged on new betas and RCs, and a wiki
page where they can indicate that they've run tests (and whether or not
they had issues). That way, you could have a targetted nag list -- "Hey,
I don't see an update from you -- RUN THE TESTS!", and a deadline
whereby if they haven't run them, they accept the consequences. :)
We send out mails like this: http://news.php.net/php.qa/65903 to
maintainers of different PHP projects who have opted in for every RC. I
usually get one response and lots of black-hole void reactions.
For 5.3.9 I'll make more responses a release requirement. (have to check
the current recipient list and probably update that to define that
closer, will also work w/ Stas/dsp on that to have it identical for 5.4)
I could also see this being an interesting peer-pressure move -- "First
to test!", "We tested last week; how come you haven't?", etc.
This also means that this list has more traffic. Which makes it more
likely to be ignored ...
johannes
I could also see this being an interesting peer-pressure move -- "First
to test!", "We tested last week; how come you haven't?", etc.
Speaking of testing, the commit http://svn.php.net/viewvc?view=revision&revision=317183
doesn't have any...
Who amongst the vocal supporters of the change is volunteering for this task?
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
I could also see this being an interesting peer-pressure move -- "First
to test!", "We tested last week; how come you haven't?", etc.Speaking of testing, the commit
http://svn.php.net/viewvc?view=revision&revision=317183
doesn't have any...Who amongst the vocal supporters of the change is volunteering for this
task?
I committed a test about 2 hours before you posted this message:
http://svn.php.net/viewvc?view=revision&revision=317208
-Rasmus
I could also see this being an interesting peer-pressure move -- "First
to test!", "We tested last week; how come you haven't?", etc.Speaking of testing, the commit
http://svn.php.net/viewvc?view=revision&revision=317183
doesn't have any...Who amongst the vocal supporters of the change is volunteering for this
task?I committed a test about 2 hours before you posted this message:
http://svn.php.net/viewvc?view=revision&revision=317208
-Rasmus
I don't see is_a or is_subclass_of in that test. Did I miss something?
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
I could also see this being an interesting peer-pressure move -- "First
to test!", "We tested last week; how come you haven't?", etc.Speaking of testing, the commit
http://svn.php.net/viewvc?view=revision&revision=317183
doesn't have any...Who amongst the vocal supporters of the change is volunteering for this
task?I committed a test about 2 hours before you posted this message:
http://svn.php.net/viewvc?view=revision&revision=317208
-Rasmus
I don't see is_a or is_subclass_of in that test. Did I miss something?
Ah, oops, wrong commit. I thought you meant the lack of a test in my
initial commit to fix 55767
I could also see this being an interesting peer-pressure move -- "First
to test!", "We tested last week; how come you haven't?", etc.Speaking of testing, the commit
http://svn.php.net/viewvc?view=revision&revision=317183
doesn't have any...Who amongst the vocal supporters of the change is volunteering for this
task?I committed a test about 2 hours before you posted this message:
http://svn.php.net/viewvc?view=revision&revision=317208
-Rasmus
I don't see is_a or is_subclass_of in that test. Did I miss something?
Yeah, got the wrong commit when I brought up that link. Had a cached
copy of my fix for 55767 and the wifi is wonky here.
I could also see this being an interesting peer-pressure move -- "First
to test!", "We tested last week; how come you haven't?", etc.Speaking of testing, the commit
http://svn.php.net/viewvc?view=revision&revision=317183
doesn't have any...Who amongst the vocal supporters of the change is volunteering for this
task?I committed a test about 2 hours before you posted this message:
http://svn.php.net/viewvc?view=revision&revision=317208
-Rasmus
I don't see is_a or is_subclass_of in that test. Did I miss something?
Yeah, got the wrong commit when I brought up that link. Had a cached
copy of my fix for 55767 and the wifi is wonky here.
No probs.
Let's see if the people who speak about PHP & testing & compatibility actually
do care enough about it to submit some tests.
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
On Fri, Sep 23, 2011 at 20:38, Christopher Jones
christopher.jones@oracle.com wrote:
I could also see this being an interesting peer-pressure move --
"First
to test!", "We tested last week; how come you haven't?", etc.Speaking of testing, the commit
http://svn.php.net/viewvc?view=revision&revision=317183
doesn't have any...Who amongst the vocal supporters of the change is volunteering for this
task?I committed a test about 2 hours before you posted this message:
http://svn.php.net/viewvc?view=revision&revision=317208
-Rasmus
I don't see is_a or is_subclass_of in that test. Did I miss something?
Yeah, got the wrong commit when I brought up that link. Had a cached
copy of my fix for 55767 and the wifi is wonky here.No probs.
Let's see if the people who speak about PHP & testing & compatibility
actually
do care enough about it to submit some tests.
Just for the record, the original behavior was covered by tests, but
the test was changed when introducing the new behavior.
And that is something we actually do quite a bit. Modify existing
tests to fit new behavior..
The problem is our tests are all over the place. Testing waaay to many
things at once, making it very difficult to spot actually wrong
behaviors and broken functionality :(
-Hannes
hi Rasmus,
Should we work up a basic PEAR test case that we can add to our
tests?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
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
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.
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
Zitat von Pierre Joye pierre.php@gmail.com:
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.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).
If using the released versions, that would add another 5000 tests.
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
Zitat von Pierre Joye pierre.php@gmail.com:
On Fri, Sep 23, 2011 at 12:23 PM, Rasmus Lerdorf rasmus@lerdorf.com
wrote: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.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).If using the released versions, that would add another 5000 tests.
http://www.downforeveryoneorjustme.com/ci.horde.org
"It's not just you! http://ci.horde.org looks down from here."
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Zitat von Ferenc Kovacs tyra3l@gmail.com:
Zitat von Pierre Joye pierre.php@gmail.com:
On Fri, Sep 23, 2011 at 12:23 PM, Rasmus Lerdorf rasmus@lerdorf.com
wrote: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.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).If using the released versions, that would add another 5000 tests.
http://www.downforeveryoneorjustme.com/ci.horde.org
"It's not just you! http://ci.horde.org looks down from here."
FWIW it seems to be more stable now since upgrading to a newer Jenkins
version.
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
Zitat von Ferenc Kovacs tyra3l@gmail.com:
Zitat von Pierre Joye pierre.php@gmail.com:
On Fri, Sep 23, 2011 at 12:23 PM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:
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.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).If using the released versions, that would add another 5000 tests.
http://www.**downforeveryoneorjustme.com/**ci.horde.orghttp://www.downforeveryoneorjustme.com/ci.horde.org
"It's not just you! http://ci.horde.org looks down from here."FWIW it seems to be more stable now since upgrading to a newer Jenkins
version.
nice, thanks! :)
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
hi Jan!
FWIW it seems to be more stable now since upgrading to a newer Jenkins
version.
Do you test it against php's snapshot too?
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi Jan!
FWIW it seems to be more stable now since upgrading to a newer Jenkins
version.Do you test it against php's snapshot too?
Pierre
from a quick look on their setup, they only have one node, and they are
using the global php binary, so no, they are only testing one php version,
and I don't think that it would be the snapshot.
but that would be cool. :)
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
from a quick look on their setup, they only have one node, and they are
using the global php binary, so no, they are only testing one php version,
and I don't think that it would be the snapshot.
but that would be cool. :)
It is a must and it is what we need to do.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Zitat von Pierre Joye pierre.php@gmail.com:
from a quick look on their setup, they only have one node, and they are
using the global php binary, so no, they are only testing one php version,
and I don't think that it would be the snapshot.
but that would be cool. :)
Ferenc is right, this is testing against the distro's latest version.
It is a must and it is what we need to do.
We don't have the resources to run such a node on our own. The idea
was to provide the test suite of the most recent package releases for
such a snaphot testing machine (run by the php group?)
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
hi Jan!
from a quick look on their setup, they only have one node, and they are
using the global php binary, so no, they are only testing one php
version,
and I don't think that it would be the snapshot.
but that would be cool. :)Ferenc is right, this is testing against the distro's latest version.
It is sadly not very useful for us, while being informative. To know
that something went wrong when a release is already out is too late,
let alone when the distros updated their package :)
It is a must and it is what we need to do.
We don't have the resources to run such a node on our own. The idea was to
provide the test suite of the most recent package releases for such a
snaphot testing machine (run by the php group?)
Do you have some time to setup the tests script in a VM? Then we will
use what we have already to run php's snapshot and RCs. We will share
VMs for 2-3 projects.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Zitat von Pierre Joye pierre.php@gmail.com:
hi Jan!
from a quick look on their setup, they only have one node, and they are
using the global php binary, so no, they are only testing one php
version,
and I don't think that it would be the snapshot.
but that would be cool. :)Ferenc is right, this is testing against the distro's latest version.
It is sadly not very useful for us, while being informative. To know
that something went wrong when a release is already out is too late,
let alone when the distros updated their package :)
Sure, this was just to showcase the number of tests that we already
run continuously to find regressions in our snapshots.
It is a must and it is what we need to do.
We don't have the resources to run such a node on our own. The idea was to
provide the test suite of the most recent package releases for such a
snaphot testing machine (run by the php group?)Do you have some time to setup the tests script in a VM? Then we will
use what we have already to run php's snapshot and RCs. We will share
VMs for 2-3 projects.
I'm going to check with our Jenkins guru, but I'm wondering how such a
VM should look like. Should it contain a complete Jenkins instance, or
just a checkout of the Horde packages that you would run from your own
Jenkins server(s)?
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
I'm going to check with our Jenkins guru, but I'm wondering how such a VM
should look like. Should it contain a complete Jenkins instance, or just a
checkout of the Horde packages that you would run from your own Jenkins
server(s)?
It will be no different to what you have now to run the tests locally.
All we need is a result set (json) that will be pushed in our servers
and displayed, alerts will be sent on errors, etc.
Are you online somewhere for a chat?
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Obviously I'd be keen to see this fix applied to 5.4 as the standard use
case for is_a() is mixed return testing as '$x instanceof "somestring"'
does not work.
I've drafted up a BC RFC, if anyone want to contribute - feel free to edit..
https://wiki.php.net/rfc/backwards_compatibility?
The "ideal" aim is that in future it would be better for the proposer of
BC break to have a clear way to justify it rather than do so after the
fact, or point to our rather long discussions.
Regards
Alan
hi Rasmus,
Should we work up a basic PEAR test case that we can add to our
tests?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,
Hi!
Obviously I'd be keen to see this fix applied to 5.4 as the standard use
case foris_a()is mixed return testing as '$x instanceof "somestring"'
does not work.
There is no reason to do $x instanceof "somestring" as you can do just
$x instanceof Class. And for 99% of cases I've seen the second argument
of is_a was constant - which means this code was plain wrong, there's no
reason to use is_a in such case. In case you do have to use is_a -
namely, when you have variable arguments - it would be rather strange if
first argument wouldn't support string as class name, but the second one
would, and moreover, is_subclass_of also would.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Sorry, never even noticed instanceof got fixed (in 5.1) with undefined
classes. Since it did not work when introduced, i just assumed it would
stay that way.......
Anyway, It's a pretty good justification for phased "Announced" long
term depreciation plan
in 5.4 is_a() usage called without a third argument shows depreciated
warning pointing to a message that you should use instanceof (as it has
worked ok since 5.1)
Then changing the behavior in 5.5 / 1yr+ and changing the default to
true is a BC plan.
Only downside is that users of is_a() for class string/autoload testing
have to put true at the end, and eventually can remove it after a few years.
Regards
Alan
Hi!
Obviously I'd be keen to see this fix applied to 5.4 as the standard use
case foris_a()is mixed return testing as '$x instanceof "somestring"'
does not work.There is no reason to do $x instanceof "somestring" as you can do just
$x instanceof Class. And for 99% of cases I've seen the second
argument of is_a was constant - which means this code was plain wrong,
there's no reason to use is_a in such case. In case you do have to use
is_a - namely, when you have variable arguments - it would be rather
strange if first argument wouldn't support string as class name, but
the second one would, and moreover, is_subclass_of also would.
It then reverts
is_a()back to the previous behavior, and clarifies
the documentation.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.