All,
It appears that in our efforts to optimize PHP 7 we've introduced an
inconsistency into array handling. This is demonstrated by this
script: https://3v4l.org/hVcAB
$a = 1;
unset($a);
var_dump(count($GLOBALS), $GLOBALS);
The result is that the count doesn't match the contents of the array.
It also affects objects casted to arrays in certain cases.
Here, the array has 1 element, but should have 0. Trying to access the
"1" element "a" results in a notice.
This means that the count is incorrect. This is due to the fact that
the "a" element follows an IS_INDIRECT type pointing to the other
symbol table.
A potential solution would be to make count() an O(n) operation in the
case that the hashtable is a symbol table or if it has INDIRECT
elements. Meaning that we'd compute the real count at runtime.
This obviously has performance ramifications, but we shouldn't
sacrifice consistency and behavior for performance IMHO. Especially
when it comes to core data structures.
I think this is significant enough to be a blocker to gold and that we
should fix it prior to release.
Thoughts?
Anthony
I think this is significant enough to be a blocker to gold and that we
should fix it prior to release.Thoughts?
IMHO, unless we think fixing this would require breaking binary compatibility (which I don't think is the case) - this shouldn't block 7.0.0. 7.0.0 is a lot more about getting people to start paying attention to 7.0 and start testing their codebase against it - finding both the incompatibilities in their code and, undoubtedly - the bugs we failed to find. I wish we could say this would be the last issue we find in 7.0, but I think we can all agree it's wishful thinking...
Zeev
Zeev,
I think this is significant enough to be a blocker to gold and that we
should fix it prior to release.Thoughts?
IMHO, unless we think fixing this would require breaking binary compatibility (which I don't think is the case) - this shouldn't block 7.0.0. 7.0.0 is a lot more about getting people to start paying attention to 7.0 and start testing their codebase against it - finding both the incompatibilities in their code and, undoubtedly - the bugs we failed to find. I wish we could say this would be the last issue we find in 7.0, but I think we can all agree it's wishful thinking...
Consider that Distros may very well pick whatever we call stable for
LTS releases. Meaning that non-critical (crash/security) bugs that we
miss may wind up living on for a VERY long time. If we don't intend .0
to be stable, then what's the point of versioning in the first place?
Xinchen,
Very interesting on the fix. I do think it's important for this to
land with 7, but at least we can have the discussion.
Thanks!!!
Anthony
Zeev,
I think this is significant enough to be a blocker to gold and that we
should fix it prior to release.Thoughts?
IMHO, unless we think fixing this would require breaking binary compatibility (which I don't think is the case) - this shouldn't block 7.0.0. 7.0.0 is a lot more about getting people to start paying attention to 7.0 and start testing their codebase against it - finding both the incompatibilities in their code and, undoubtedly - the bugs we failed to find. I wish we could say this would be the last issue we find in 7.0, but I think we can all agree it's wishful thinking...
Consider that Distros may very well pick whatever we call stable for
LTS releases. Meaning that non-critical (crash/security) bugs that we
miss may wind up living on for a VERY long time. If we don't intend .0
to be stable, then what's the point of versioning in the first place?Xinchen,
Very interesting on the fix. I do think it's important for this to
land with 7, but at least we can have the discussion.
I agree with Zeev here and I had a chat with Anatol about this tonight.
This is a .0.0 release. Nobody is going to take a .0.0 and push it
straight to production. And it is not going to part of any sort of LTS
distro either. It's not like LTS distros don't pick up point releases.
There is no way we will go 2 weeks without finding something for quite a
while still which can drag things out indefinitely. The question is
whether this is significant enough to postpone further. Personally I
don't think it is. Let's get 7.0.0 out the door and get ourselves on
track for regular point releases without any of this "perfect-release"
stress.
-Rasmus
Let's get 7.0.0 out the door and get ourselves on
track for regular point releases without any of this "perfect-release"
stress.-Rasmus
Can I just bring us back to a week ago when we spent a couple days
discussing the "new" release date?
There was a big push to avoid 26th due to Thanksgiving and some people went
as far as christmas.
I see here a great opportunity to delay for a good valid reason, and at the
same time solve the "clashing" date problem.
And I agree with Anthony, if we found a serious bug, let's fix it, its not
about perfect releases its about ignoring known issues.
--
Rafael Dohms
PHP Evangelist and Community Leader
http://doh.ms
http://www.amsterdamphp.nl <http://wwwamsterdamphp.nl
Let's get 7.0.0 out the door and get ourselves on
track for regular point releases without any of this "perfect-release"
stress.-Rasmus
Can I just bring us back to a week ago when we spent a couple days discussing the "new" release date?
There was a big push to avoid 26th due to Thanksgiving and some people went as far as christmas.
I see here a great opportunity to delay for a good valid reason, and at the same time solve the "clashing" date problem.
And I agree with Anthony, if we found a serious bug, let's fix it, its not about perfect releases its about ignoring known issues.
While I don't view this bug as a blocker in any way - independently I think it's a good idea to delay to next week. So thumbs up from me as well (I'm in favor of any option that doesn't push us into mid December and practically into 2016, unless we find something truly disastrous).
Zeev
Zeev,
IMHO, unless we think fixing this would require breaking binary compatibility (which I don't think is the case) - this shouldn't block 7.0.0. 7.0.0 is a lot more about getting people to start paying attention to 7.0 and start testing their codebase against it - finding both the incompatibilities in their code and, undoubtedly - the bugs we failed to find. I wish we could say this would be the last issue we find in 7.0, but I think we can all agree it's wishful thinking...
Sure, but not every issue is created equal. Not being able to trust
count() is pretty fundamental — sure, it's not "PHP segfaults when you
access a $_GET variable" bad, but it's still bad, and it's the kind of
bug that even reasonable unit tests might not find.
I agree with Zeev here and I had a chat with Anatol about this tonight.
This is a .0.0 release. Nobody is going to take a .0.0 and push it
straight to production. And it is not going to part of any sort of LTS
distro either. It's not like LTS distros don't pick up point releases.
There is no way we will go 2 weeks without finding something for quite a
while still which can drag things out indefinitely. The question is
whether this is significant enough to postpone further. Personally I
don't think it is. Let's get 7.0.0 out the door and get ourselves on
track for regular point releases without any of this "perfect-release"
stress.
I disagree completely with that. No, sensible people aren't going to
push 7.0.0 straight to production, but remember David Zuelke's e-mail
from two weeks ago about how Heroku customers with poorly chosen
version constraints might end up with it by accident. The world's not
as simple as sysadmins running "./configure && make install" any more.
As a group, we're saying that 7.0.0 is "stable". That doesn't mean
perfect, but it should mean "you can trust count()".
Here's an alternative suggestion: we've previously switched to one
week RC cycles late in the piece when trying to get major releases
stabilised and we're at the point of only fixing one or two things per
RC. That's exactly where we are now. Why don't we do that again —
release a fix for this bug as an RC 8 this week, and then do a release
on December 3 if nothing else significant comes up?
Adam
Here's an alternative suggestion: we've previously switched to one
week RC cycles late in the piece when trying to get major releases
stabilised and we're at the point of only fixing one or two things per
RC. That's exactly where we are now. Why don't we do that again —
release a fix for this bug as an RC 8 this week, and then do a release
on December 3 if nothing else significant comes up?
Still not entirely convinced this bug is major enough to warrant the
delay. It seems right on the edge to me. But since it is on the edge
there will be enough people who think it is major that we probably
should wait on it. Doing a one-week RC8 this week and aiming for
a Dec.3 release seems like a good solution to me.
-Rasmus
Here's an alternative suggestion: we've previously switched to one
week RC cycles late in the piece when trying to get major releases
stabilised and we're at the point of only fixing one or two things per
RC. That's exactly where we are now. Why don't we do that again —
release a fix for this bug as an RC 8 this week, and then do a release
on December 3 if nothing else significant comes up?Still not entirely convinced this bug is major enough to warrant the
delay. It seems right on the edge to me. But since it is on the edge
there will be enough people who think it is major that we probably
should wait on it. Doing a one-week RC8 this week and aiming for
a Dec.3 release seems like a good solution to me.
That sounds like a good compromise indeed!
Zeev,
I think this is significant enough to be a blocker to gold and that we
should fix it prior to release.Thoughts?
IMHO, unless we think fixing this would require breaking binary compatibility (which I don't think is the case) - this shouldn't block 7.0.0. 7.0.0 is a lot more about getting people to start paying attention to 7.0 and start testing their codebase against it - finding both the incompatibilities in their code and, undoubtedly - the bugs we failed to find. I wish we could say this would be the last issue we find in 7.0, but I think we can all agree it's wishful thinking...
Consider that Distros may very well pick whatever we call stable for
LTS releases. Meaning that non-critical (crash/security) bugs that we
miss may wind up living on for a VERY long time. If we don't intend .0
to be stable, then what's the point of versioning in the first place?Xinchen,
Very interesting on the fix. I do think it's important for this to
land with 7, but at least we can have the discussion.I agree with Zeev here and I had a chat with Anatol about this tonight.
This is a .0.0 release. Nobody is going to take a .0.0 and push it
straight to production. And it is not going to part of any sort of LTS
distro either. It's not like LTS distros don't pick up point releases.
There is no way we will go 2 weeks without finding something for quite a
while still which can drag things out indefinitely. The question is
whether this is significant enough to postpone further. Personally I
don't think it is. Let's get 7.0.0 out the door and get ourselves on
track for regular point releases without any of this "perfect-release"
stress.-Rasmus
Sorry to pop by here but Zeev and Rasmus are saying some things in
general that I strongly disagree with. I was going to just carry on
with my day after mentioning my concerns on Twitter, but I was asked
to raise them in here as well. Here goes.
Firstly, Zeev: "7.0.0 is a lot more about getting people to start
paying attention to 7.0 and start testing their codebase against it "
This is absolutely not at all what a final release is for. Whilst
nobody expects a major final release to be 100% bug free (no software
is), knowing about a bug and saying "meh whatever let those nerds find
out what broke later" is just not ok. Not ok at all.
Fix bugs as they come up, absolutely - that's how we all do
open-source - but don't just shout YOLO and ship it anyway, especially
when folks like Anthony are saying they think it's a concern. Nobody
replied here saying "I don't think this bug is going to be an issue in
the wild because X", you just replied saying "Who cares".
Rasmus, with all due respect, I think you work in a slightly different
realm of reality to a huge number of PHP developers. To say "This is a
.0.0 release. Nobody is going to take a .0.0 and push it straight to
production." is very very very inaccurate of many developers
realities. That's like Apple saying "Who gives a shit if we ship El
Capitan with known bugs, it's not like people upgrade when it comes
out." shortly before their upgrade servers go down because 90% of
Macbook owners try to upgrade immediately.
I know a fair few people - like myself - hold off due to concern of
bugs being there for a while, and many people wait for a patch, but to
say those who will upgrade quickly are statistically insignificant is
completely and entirely false.
People might think that hosts will barely even have PHP 7.0.X ready
before 7.0.1 is out, but they are unfortunately ignorant of the speed
in which hosts these days offer new versions. I get PR requests to
http://phpversions.info/php-7/ before I see the PHP.net announcement
emails half the time, and the other half are <48 hours after. Hosts
upgrade quickly these days, so you can't use their previously
snail-like pace as an argument for shipping broken stuff and hoping
nobody will use it.
If you folks want to have a conversation about the impact and
significance of this specific bug then that's cool; I defer to Anthony
and others smarter than myself for that. I just ask that you please
please please don't use those "YOLO F**K IT WHO CARES" arguments
you've used above. They're not accurate of the community and they make
the project seem reckless and laughable.
tl:dr; .0.0 is not a RC.
I can hardly believe this conversation has gone the way it has ...
I'm only happy the release managers are the ones to make the decision, and
have no reason to distrust their judgement.
Can we get a release manager to start saying reasonable things please ...
Cheers
Joe
On Sun, Nov 22, 2015 at 12:19 PM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:Zeev,
On 22 בנוב׳ 2015, at 0:47, Anthony Ferrara ircmaxell@gmail.com
wrote:I think this is significant enough to be a blocker to gold and that we
should fix it prior to release.Thoughts?
IMHO, unless we think fixing this would require breaking binary
compatibility (which I don't think is the case) - this shouldn't block
7.0.0. 7.0.0 is a lot more about getting people to start paying attention
to 7.0 and start testing their codebase against it - finding both the
incompatibilities in their code and, undoubtedly - the bugs we failed to
find. I wish we could say this would be the last issue we find in 7.0, but
I think we can all agree it's wishful thinking...Consider that Distros may very well pick whatever we call stable for
LTS releases. Meaning that non-critical (crash/security) bugs that we
miss may wind up living on for a VERY long time. If we don't intend .0
to be stable, then what's the point of versioning in the first place?Xinchen,
Very interesting on the fix. I do think it's important for this to
land with 7, but at least we can have the discussion.I agree with Zeev here and I had a chat with Anatol about this tonight.
This is a .0.0 release. Nobody is going to take a .0.0 and push it
straight to production. And it is not going to part of any sort of LTS
distro either. It's not like LTS distros don't pick up point releases.
There is no way we will go 2 weeks without finding something for quite a
while still which can drag things out indefinitely. The question is
whether this is significant enough to postpone further. Personally I
don't think it is. Let's get 7.0.0 out the door and get ourselves on
track for regular point releases without any of this "perfect-release"
stress.-Rasmus
Sorry to pop by here but Zeev and Rasmus are saying some things in
general that I strongly disagree with. I was going to just carry on
with my day after mentioning my concerns on Twitter, but I was asked
to raise them in here as well. Here goes.Firstly, Zeev: "7.0.0 is a lot more about getting people to start
paying attention to 7.0 and start testing their codebase against it "This is absolutely not at all what a final release is for. Whilst
nobody expects a major final release to be 100% bug free (no software
is), knowing about a bug and saying "meh whatever let those nerds find
out what broke later" is just not ok. Not ok at all.Fix bugs as they come up, absolutely - that's how we all do
open-source - but don't just shout YOLO and ship it anyway, especially
when folks like Anthony are saying they think it's a concern. Nobody
replied here saying "I don't think this bug is going to be an issue in
the wild because X", you just replied saying "Who cares".Rasmus, with all due respect, I think you work in a slightly different
realm of reality to a huge number of PHP developers. To say "This is a
.0.0 release. Nobody is going to take a .0.0 and push it straight to
production." is very very very inaccurate of many developers
realities. That's like Apple saying "Who gives a shit if we ship El
Capitan with known bugs, it's not like people upgrade when it comes
out." shortly before their upgrade servers go down because 90% of
Macbook owners try to upgrade immediately.I know a fair few people - like myself - hold off due to concern of
bugs being there for a while, and many people wait for a patch, but to
say those who will upgrade quickly are statistically insignificant is
completely and entirely false.People might think that hosts will barely even have PHP 7.0.X ready
before 7.0.1 is out, but they are unfortunately ignorant of the speed
in which hosts these days offer new versions. I get PR requests to
http://phpversions.info/php-7/ before I see the PHP.net announcement
emails half the time, and the other half are <48 hours after. Hosts
upgrade quickly these days, so you can't use their previously
snail-like pace as an argument for shipping broken stuff and hoping
nobody will use it.If you folks want to have a conversation about the impact and
significance of this specific bug then that's cool; I defer to Anthony
and others smarter than myself for that. I just ask that you please
please please don't use those "YOLO F**K IT WHO CARES" arguments
you've used above. They're not accurate of the community and they make
the project seem reckless and laughable.tl:dr; .0.0 is not a RC.
Hi,
-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Sunday, November 22, 2015 11:20 PM
To: Anthony Ferrara ircmaxell@gmail.com; Zeev Suraski zeev@zend.com
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] INDRECT in arrays causescount()to become
unpredictableZeev,
I think this is significant enough to be a blocker to gold and that
we should fix it prior to release.Thoughts?
IMHO, unless we think fixing this would require breaking binary compatibility
(which I don't think is the case) - this shouldn't block 7.0.0. 7.0.0 is a lot more
about getting people to start paying attention to 7.0 and start testing their
codebase against it - finding both the incompatibilities in their code and,
undoubtedly - the bugs we failed to find. I wish we could say this would be the
last issue we find in 7.0, but I think we can all agree it's wishful thinking...Consider that Distros may very well pick whatever we call stable for
LTS releases. Meaning that non-critical (crash/security) bugs that we
miss may wind up living on for a VERY long time. If we don't intend .0
to be stable, then what's the point of versioning in the first place?Xinchen,
Very interesting on the fix. I do think it's important for this to
land with 7, but at least we can have the discussion.I agree with Zeev here and I had a chat with Anatol about this tonight.
This is a .0.0 release. Nobody is going to take a .0.0 and push it straight to
production. And it is not going to part of any sort of LTS distro either. It's not like
LTS distros don't pick up point releases.
There is no way we will go 2 weeks without finding something for quite a while
still which can drag things out indefinitely. The question is whether this is
significant enough to postpone further. Personally I don't think it is. Let's get
7.0.0 out the door and get ourselves on track for regular point releases without
any of this "perfect-release"
stress.
From what I was merging for 7.0.0, I see that there are quite some primitive bug fixes, a couple of non critical 7.0 bugs and 2 bugs merged up from 5.6. The issue with the symtable counter stands at some point around the critical border. I personally would see it as not crossing that border.
So based on this, I'd rather go by releasing. The bug list after RC7 looks pretty much like a regular patch release, or even better. Comparing to RC6 where it was started to be tested obviously some more intensively, RC7 looks more like lost attention. We could go with more RC, sure. However in that case IMO we would catch bugs at very low speed with no guarantee we have a good thing at the end when we "think" it's good. This will cause us to defer things for much longer time. Releasing on 26th (or on 3rd with respect to Thanksgiving, if there are still strong concerns) were IMHO convenient for this reasons.
People that don't test RC won't start to test any later RC anyway. People that don't test RC will start to use GA and that will lead to bug reports, in any case. So IMHO at this point we are good enough to do the first release with all the known bugs fixed, with the knowledge that no critical bugs are present, with the knowledge that community projects like Drupal 8, Symfony, etc. report the green tests, and with intention to get people waiting for GA involved.
Regards
Anatol
Morning Anatol,
People that don't test RC won't start to test any later RC anyway.
This wasn't reported by "people", this was found by one of us.
The problem isn't only that we have a bug in symbol tables, the problem is
that the bug was found so very late in the process.
We cannot reasonably have confidence that no other such bugs exist.
I think it doesn't make sense to push forward with the current release time
table now. I think it makes sense to do another RC and give us a little
bit longer to test.
Please reconsider.
Cheers
Joe
On Mon, Nov 23, 2015 at 7:28 AM, Anatol Belski anatol.php@belski.net
wrote:
Hi,
-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Sunday, November 22, 2015 11:20 PM
To: Anthony Ferrara ircmaxell@gmail.com; Zeev Suraski zeev@zend.com
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] INDRECT in arrays causescount()to become
unpredictableZeev,
On 22 בנוב׳ 2015, at 0:47, Anthony Ferrara ircmaxell@gmail.com
wrote:I think this is significant enough to be a blocker to gold and that
we should fix it prior to release.Thoughts?
IMHO, unless we think fixing this would require breaking binary
compatibility
(which I don't think is the case) - this shouldn't block 7.0.0. 7.0.0
is a lot more
about getting people to start paying attention to 7.0 and start testing
their
codebase against it - finding both the incompatibilities in their code
and,
undoubtedly - the bugs we failed to find. I wish we could say this
would be the
last issue we find in 7.0, but I think we can all agree it's wishful
thinking...Consider that Distros may very well pick whatever we call stable for
LTS releases. Meaning that non-critical (crash/security) bugs that we
miss may wind up living on for a VERY long time. If we don't intend .0
to be stable, then what's the point of versioning in the first place?Xinchen,
Very interesting on the fix. I do think it's important for this to
land with 7, but at least we can have the discussion.I agree with Zeev here and I had a chat with Anatol about this tonight.
This is a .0.0 release. Nobody is going to take a .0.0 and push it
straight to
production. And it is not going to part of any sort of LTS distro
either. It's not like
LTS distros don't pick up point releases.
There is no way we will go 2 weeks without finding something for quite a
while
still which can drag things out indefinitely. The question is whether
this is
significant enough to postpone further. Personally I don't think it is.
Let's get
7.0.0 out the door and get ourselves on track for regular point releases
without
any of this "perfect-release"
stress.From what I was merging for 7.0.0, I see that there are quite some
primitive bug fixes, a couple of non critical 7.0 bugs and 2 bugs merged up
from 5.6. The issue with the symtable counter stands at some point around
the critical border. I personally would see it as not crossing that border.So based on this, I'd rather go by releasing. The bug list after RC7 looks
pretty much like a regular patch release, or even better. Comparing to RC6
where it was started to be tested obviously some more intensively, RC7
looks more like lost attention. We could go with more RC, sure. However in
that case IMO we would catch bugs at very low speed with no guarantee we
have a good thing at the end when we "think" it's good. This will cause us
to defer things for much longer time. Releasing on 26th (or on 3rd with
respect to Thanksgiving, if there are still strong concerns) were IMHO
convenient for this reasons.People that don't test RC won't start to test any later RC anyway. People
that don't test RC will start to use GA and that will lead to bug reports,
in any case. So IMHO at this point we are good enough to do the first
release with all the known bugs fixed, with the knowledge that no critical
bugs are present, with the knowledge that community projects like Drupal 8,
Symfony, etc. report the green tests, and with intention to get people
waiting for GA involved.Regards
Anatol
I may have misunderstood, will this be fixed before GA or not ?
Cheers
Joe
Morning Anatol,
People that don't test RC won't start to test any later RC anyway.
This wasn't reported by "people", this was found by one of us.
The problem isn't only that we have a bug in symbol tables, the problem is
that the bug was found so very late in the process.We cannot reasonably have confidence that no other such bugs exist.
I think it doesn't make sense to push forward with the current release
time table now. I think it makes sense to do another RC and give us a
little bit longer to test.Please reconsider.
Cheers
JoeOn Mon, Nov 23, 2015 at 7:28 AM, Anatol Belski anatol.php@belski.net
wrote:Hi,
-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Sunday, November 22, 2015 11:20 PM
To: Anthony Ferrara ircmaxell@gmail.com; Zeev Suraski zeev@zend.com
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] INDRECT in arrays causescount()to become
unpredictableZeev,
On 22 בנוב׳ 2015, at 0:47, Anthony Ferrara ircmaxell@gmail.com
wrote:I think this is significant enough to be a blocker to gold and that
we should fix it prior to release.Thoughts?
IMHO, unless we think fixing this would require breaking binary
compatibility
(which I don't think is the case) - this shouldn't block 7.0.0. 7.0.0
is a lot more
about getting people to start paying attention to 7.0 and start testing
their
codebase against it - finding both the incompatibilities in their code
and,
undoubtedly - the bugs we failed to find. I wish we could say this
would be the
last issue we find in 7.0, but I think we can all agree it's wishful
thinking...Consider that Distros may very well pick whatever we call stable for
LTS releases. Meaning that non-critical (crash/security) bugs that we
miss may wind up living on for a VERY long time. If we don't intend .0
to be stable, then what's the point of versioning in the first place?Xinchen,
Very interesting on the fix. I do think it's important for this to
land with 7, but at least we can have the discussion.I agree with Zeev here and I had a chat with Anatol about this tonight.
This is a .0.0 release. Nobody is going to take a .0.0 and push it
straight to
production. And it is not going to part of any sort of LTS distro
either. It's not like
LTS distros don't pick up point releases.
There is no way we will go 2 weeks without finding something for quite
a while
still which can drag things out indefinitely. The question is whether
this is
significant enough to postpone further. Personally I don't think it is.
Let's get
7.0.0 out the door and get ourselves on track for regular point
releases without
any of this "perfect-release"
stress.From what I was merging for 7.0.0, I see that there are quite some
primitive bug fixes, a couple of non critical 7.0 bugs and 2 bugs merged up
from 5.6. The issue with the symtable counter stands at some point around
the critical border. I personally would see it as not crossing that border.So based on this, I'd rather go by releasing. The bug list after RC7
looks pretty much like a regular patch release, or even better. Comparing
to RC6 where it was started to be tested obviously some more intensively,
RC7 looks more like lost attention. We could go with more RC, sure. However
in that case IMO we would catch bugs at very low speed with no guarantee we
have a good thing at the end when we "think" it's good. This will cause us
to defer things for much longer time. Releasing on 26th (or on 3rd with
respect to Thanksgiving, if there are still strong concerns) were IMHO
convenient for this reasons.People that don't test RC won't start to test any later RC anyway. People
that don't test RC will start to use GA and that will lead to bug reports,
in any case. So IMHO at this point we are good enough to do the first
release with all the known bugs fixed, with the knowledge that no critical
bugs are present, with the knowledge that community projects like Drupal 8,
Symfony, etc. report the green tests, and with intention to get people
waiting for GA involved.Regards
Anatol
Hey:
Morning Anatol,
People that don't test RC won't start to test any later RC anyway.
This wasn't reported by "people", this was found by one of us.
The problem isn't only that we have a bug in symbol tables, the problem is
that the bug was found so very late in the process.We cannot reasonably have confidence that no other such bugs exist.
There will always be bugs. that's why we will have 7.0.1, 7.0.2 , the
problem is, wether the bug is serious, does it affects normal usage. we
will try our best to avoid such bugs before release, but we should not
freeze our release roadmap to wait them raise up..
for this one, I don't see how serious it is. so I may consider it as a
general bug.
thanks
I think it doesn't make sense to push forward with the current release time
table now. I think it makes sense to do another RC and give us a little
bit longer to test.Please reconsider.
Cheers
JoeOn Mon, Nov 23, 2015 at 7:28 AM, Anatol Belski anatol.php@belski.net
wrote:Hi,
-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Sunday, November 22, 2015 11:20 PM
To: Anthony Ferrara ircmaxell@gmail.com; Zeev Suraski <zeev@zend.comCc: internals@lists.php.net
Subject: Re: [PHP-DEV] INDRECT in arrays causescount()to become
unpredictableZeev,
On Sat, Nov 21, 2015 at 11:52 PM, Zeev Suraski zeev@zend.com
wrote:On 22 בנוב׳ 2015, at 0:47, Anthony Ferrara ircmaxell@gmail.com
wrote:I think this is significant enough to be a blocker to gold and that
we should fix it prior to release.Thoughts?
IMHO, unless we think fixing this would require breaking binary
compatibility
(which I don't think is the case) - this shouldn't block 7.0.0. 7.0.0
is a lot more
about getting people to start paying attention to 7.0 and start testing
their
codebase against it - finding both the incompatibilities in their code
and,
undoubtedly - the bugs we failed to find. I wish we could say this
would be the
last issue we find in 7.0, but I think we can all agree it's wishful
thinking...Consider that Distros may very well pick whatever we call stable for
LTS releases. Meaning that non-critical (crash/security) bugs that we
miss may wind up living on for a VERY long time. If we don't intend
.0
to be stable, then what's the point of versioning in the first place?Xinchen,
Very interesting on the fix. I do think it's important for this to
land with 7, but at least we can have the discussion.I agree with Zeev here and I had a chat with Anatol about this tonight.
This is a .0.0 release. Nobody is going to take a .0.0 and push it
straight to
production. And it is not going to part of any sort of LTS distro
either. It's not like
LTS distros don't pick up point releases.
There is no way we will go 2 weeks without finding something for quite
a
while
still which can drag things out indefinitely. The question is whether
this is
significant enough to postpone further. Personally I don't think it is.
Let's get
7.0.0 out the door and get ourselves on track for regular point
releases
without
any of this "perfect-release"
stress.From what I was merging for 7.0.0, I see that there are quite some
primitive bug fixes, a couple of non critical 7.0 bugs and 2 bugs merged
up
from 5.6. The issue with the symtable counter stands at some point around
the critical border. I personally would see it as not crossing that
border.So based on this, I'd rather go by releasing. The bug list after RC7
looks
pretty much like a regular patch release, or even better. Comparing to
RC6
where it was started to be tested obviously some more intensively, RC7
looks more like lost attention. We could go with more RC, sure. However
in
that case IMO we would catch bugs at very low speed with no guarantee we
have a good thing at the end when we "think" it's good. This will cause
us
to defer things for much longer time. Releasing on 26th (or on 3rd with
respect to Thanksgiving, if there are still strong concerns) were IMHO
convenient for this reasons.People that don't test RC won't start to test any later RC anyway. People
that don't test RC will start to use GA and that will lead to bug
reports,
in any case. So IMHO at this point we are good enough to do the first
release with all the known bugs fixed, with the knowledge that no
critical
bugs are present, with the knowledge that community projects like Drupal
8,
Symfony, etc. report the green tests, and with intention to get people
waiting for GA involved.Regards
Anatol
--
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hey:
Morning Anatol,
People that don't test RC won't start to test any later RC anyway.
This wasn't reported by "people", this was found by one of us.
The problem isn't only that we have a bug in symbol tables, the problem is
that the bug was found so very late in the process.We cannot reasonably have confidence that no other such bugs exist.
There will always be bugs. that's why we will have 7.0.1, 7.0.2 , the
problem is, wether the bug is serious, does it affects normal usage. we
will try our best to avoid such bugs before release, but we should not
freeze our release roadmap to wait them raise up..for this one, I don't see how serious it is. so I may consider it as a
general bug.thanks
I think it doesn't make sense to push forward with the current release time
table now. I think it makes sense to do another RC and give us a little
bit longer to test.Please reconsider.
Cheers
Joe--
Xinchen Hui
@Laruence
http://www.laruence.com/
The "There will always be bugs" argument is a strawman, nobody is
saying wait until it's perfect.
People in this thread are consistently conflating "there will always
be bugs" with "lets just ignore this bug which is 'around critical'
and crack on because yolo."
I can only agree with Phil here. +1 for 1 week RCs if we're aiming at Dec
3rd anyway.
Thanks, Niklas
The "There will always be bugs" argument is a strawman, nobody is
saying wait until it's perfect.People in this thread are consistently conflating "there will always
be bugs" with "lets just ignore this bug which is 'around critical'
and crack on because yolo."
You seem to be confused Phil. Nobody is arguing that this bug shouldn't
be fixed. The question is all about how severe it is and whether it
should trigger another release candidate.
-Rasmus
The "There will always be bugs" argument is a strawman, nobody is
saying wait until it's perfect.People in this thread are consistently conflating "there will always
be bugs" with "lets just ignore this bug which is 'around critical'
and crack on because yolo."You seem to be confused Phil. Nobody is arguing that this bug shouldn't
be fixed. The question is all about how severe it is and whether it
should trigger another release candidate.-Rasmus
Am I missing something here? We found a bug, it was fixed, so if we tag .0
right now, that bug wouldn't be in .0? Not sure I see the issue here?
~C
The "There will always be bugs" argument is a strawman, nobody is
saying wait until it's perfect.People in this thread are consistently conflating "there will always
be bugs" with "lets just ignore this bug which is 'around critical'
and crack on because yolo."You seem to be confused Phil. Nobody is arguing that this bug shouldn't
be fixed. The question is all about how severe it is and whether it
should trigger another release candidate.
Exactly. And those of you who read Xinchen's analysis of the bug should know that this is not a critical bug, and IMHO, not borderline critical either, especially considering it only affects symbol tables - not arrays.
If every bug of that (relatively small) magnitude delays the release - and prevents the code base from being tested en masse - we'd effectively be putting ourselves into an endless - or at least a very long loop, given the very limited number of people currently evaluating 7.0. As soon as it does get released - we'd have orders of magnitude more people testing it than we have now, speeding up the process (of finding bugs) tremendously.
Regarding whether people do and/or should expect 7.0.0 to be production quality -- or whether that's realistic that people would move production workloads to 7.0.0 before 7.0.1 or even 7.0.2 is out - we (as in internals@) can agree to disagree.
Zeev
The "There will always be bugs" argument is a strawman, nobody is
saying wait until it's perfect.People in this thread are consistently conflating "there will always
be bugs" with "lets just ignore this bug which is 'around critical'
and crack on because yolo."You seem to be confused Phil. Nobody is arguing that this bug shouldn't
be fixed. The question is all about how severe it is and whether it
should trigger another release candidate.
Do I understand that you'd like to release 7.0.0 as 7.0.0RC7 + the count fix on Thursday?
I don't think we should push out 7.0.0 without the count fix, but I also don't think it warrants another RC.
If people think it needs another RC, then perhaps do one on Thu 26th with just RCA+ count fix, plus final on Thu Dec 3rd?
cheers,
Derick
The "There will always be bugs" argument is a strawman, nobody is
saying wait until it's perfect.People in this thread are consistently conflating "there will always
be bugs" with "lets just ignore this bug which is 'around critical'
and crack on because yolo."You seem to be confused Phil. Nobody is arguing that this bug shouldn't
be fixed. The question is all about how severe it is and whether it
should trigger another release candidate.Do I understand that you'd like to release 7.0.0 as 7.0.0RC7 + the count fix on Thursday?
Yes
I don't think we should push out 7.0.0 without the count fix, but I also don't think it warrants another RC.
If people think it needs another RC, then perhaps do one on Thu 26th with just RCA+ count fix, plus final on Thu Dec 3rd?
I am ok with either. I don't think the count fix is destabilizing enough to warrant another RC. The fix seems simple and localized to me, but either people are confused, or they genuinely feel strongly enough that this is indicative of further problems and another RC will provide us with more time to find similar issues or perhaps just give everyone a sense of confidence in the release.
There is also the fact that a lot of us are in Paris this week and and at least some of us will be in transit on the 26th so a one-week delay might be a good idea for that reason alone.
-Rasmus
The "There will always be bugs" argument is a strawman, nobody is
saying wait until it's perfect.People in this thread are consistently conflating "there will always
be bugs" with "lets just ignore this bug which is 'around critical'
and crack on because yolo."You seem to be confused Phil. Nobody is arguing that this bug shouldn't
be fixed. The question is all about how severe it is and whether it
should trigger another release candidate.Do I understand that you'd like to release 7.0.0 as 7.0.0RC7 + the count fix on Thursday?
Yes
I don't think we should push out 7.0.0 without the count fix, but I also don't think it warrants another RC.
If people think it needs another RC, then perhaps do one on Thu 26th with just RCA+ count fix, plus final on Thu Dec 3rd?
I am ok with either. I don't think the count fix is destabilizing enough to warrant another RC. The fix seems simple and localized to me, but either people are confused, or they genuinely feel strongly enough that this is indicative of further problems and another RC will provide us with more time to find similar issues or perhaps just give everyone a sense of confidence in the release.
There is also the fact that a lot of us are in Paris this week and and at least some of us will be in transit on the 26th so a one-week delay might be a good idea for that reason alone.
I'am balanced.
We discovered a bug, we have a fix , the fix is easy, self contained,
reviewed by many eyes.
So, we have all we need for a GA now, this week, no ?
Pushing another RC is all right, but if we find new bugs in this RC,
some that could be critical, then we'll postpone GA to January,
because we'll then fall in mid-December, etc...
We all have eyes, we all can spot bugs whenever we want to. Why another RC now ?
With another RC, we have time to concentrate on the code, OK, but we
still have this time if we are in GA, as we'll have anyway a 7.0.1
coming shortly after...
I'm not really +1 for another RC this week, but better for a GA. But
that's my opinion...
Julien.P
genuinely feel strongly enough that this is indicative of further
problems and another RC will provide us with more time to find similar
issues or perhaps just give everyone a sense of confidence in the release.
It's both of those things.
Another week isn't going to cost us anything.
We don't want to destroy the momentum 7 seems to be gathering in the
community ... I think this a good reason to postpone for another week, to
inspire confidence in those people responsible for making the decision to
adopt ... and possibly good reason to not wait another two weeks.
No one is expecting 0.0 or any version to be bug free, but the simplicity
of the fix says nothing about the seriousness of the bug. I think it quite
serious because we are a few days from GA, had this been found a month
ago it wouldn't seem so serious.
Pushing ahead like nothing happened doesn't seem smart, pushing ahead at a
cautious pace does.
Cheers
Joe
On Mon, Nov 23, 2015 at 11:17 AM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:On November 23, 2015 10:08:18 AM GMT+01:00, Rasmus Lerdorf <
rasmus@lerdorf.com> wrote:The "There will always be bugs" argument is a strawman, nobody is
saying wait until it's perfect.People in this thread are consistently conflating "there will always
be bugs" with "lets just ignore this bug which is 'around critical'
and crack on because yolo."You seem to be confused Phil. Nobody is arguing that this bug shouldn't
be fixed. The question is all about how severe it is and whether it
should trigger another release candidate.Do I understand that you'd like to release 7.0.0 as 7.0.0RC7 + the
count fix on Thursday?Yes
I don't think we should push out 7.0.0 without the count fix, but I
also don't think it warrants another RC.If people think it needs another RC, then perhaps do one on Thu 26th
with just RCA+ count fix, plus final on Thu Dec 3rd?I am ok with either. I don't think the count fix is destabilizing enough
to warrant another RC. The fix seems simple and localized to me, but either
people are confused, or they genuinely feel strongly enough that this is
indicative of further problems and another RC will provide us with more
time to find similar issues or perhaps just give everyone a sense of
confidence in the release.There is also the fact that a lot of us are in Paris this week and and
at least some of us will be in transit on the 26th so a one-week delay
might be a good idea for that reason alone.I'am balanced.
We discovered a bug, we have a fix , the fix is easy, self contained,
reviewed by many eyes.So, we have all we need for a GA now, this week, no ?
Pushing another RC is all right, but if we find new bugs in this RC,
some that could be critical, then we'll postpone GA to January,
because we'll then fall in mid-December, etc...We all have eyes, we all can spot bugs whenever we want to. Why another RC
now ?
With another RC, we have time to concentrate on the code, OK, but we
still have this time if we are in GA, as we'll have anyway a 7.0.1
coming shortly after...I'm not really +1 for another RC this week, but better for a GA. But
that's my opinion...Julien.P
No one is expecting 0.0 or any version to be bug free, but the simplicity of the fix says nothing about the seriousness of the bug. I think it quite serious because we are a few days from GA, had this been found a month ago it wouldn't seem so serious.
No, but both the seriousness of the bug AND the simplicity of the fix sit squarely outside any sort of "critical" definition.
The bug simply has the unfortunate connotation of being associated with arrays, but is not - it's only about count()ing symbol tables. The fix itself is very localized too and was peer reviewed, so I don't feel as if we'd be living on the edge of we'd be releasing without an extra RC.
My main concern is that of we're treating this issue as a semi blocker - it's almost unthinkable we won't find something of similar (small) magnitude in the next seven days. That's my only concern with releasing next week,m. Would people here again demand to delay, even if the impact is very limited - as is the case with this count() issue? If it wasn't for that concern, I'd probably be in favor of delaying.
Zeev
No one is expecting 0.0 or any version to be bug free, but the simplicity of the fix says nothing about the seriousness of the bug. I think it quite serious because we are a few days from GA, had this been found a month ago it wouldn't seem so serious.
No, but both the seriousness of the bug AND the simplicity of the fix sit squarely outside any sort of "critical" definition.
The bug simply has the unfortunate connotation of being associated with arrays, but is not - it's only about
count()ing symbol tables. The fix itself is very localized too and was peer reviewed, so I don't feel as if we'd be living on the edge of we'd be releasing without an extra RC.My main concern is that of we're treating this issue as a semi blocker - it's almost unthinkable we won't find something of similar (small) magnitude in the next seven days. That's my only concern with releasing next week,m. Would people here again demand to delay, even if the impact is very limited - as is the case with this
count()issue? If it wasn't for that concern, I'd probably be in favor of delaying.
I think this was mostly a PR failure on my part actually. If I/we are a bit more careful about how we handle similar issues and the people lurking with itchy Twitter trigger fingers would spend a bit more time looking into the details we should all be able to get along and get a good launch with no controversy on Dec.3.
-Rasmus
Zeev and all,
No one is expecting 0.0 or any version to be bug free, but the simplicity of the fix says nothing about the seriousness of the bug. I think it quite serious because we are a few days from GA, had this been found a month ago it wouldn't seem so serious.
No, but both the seriousness of the bug AND the simplicity of the fix sit squarely outside any sort of "critical" definition.
Perhaps, except that this bug was known by engine maintainers for
months. It actually took one of them saying it outright in a chat room
for me to be like "WTFBBQ" and raising this thread.
That seriously shakes confidence in stability. What else is known but
not common knowledge? What else is not known? etc.
The bug simply has the unfortunate connotation of being associated with arrays, but is not - it's only about
count()ing symbol tables. The fix itself is very localized too and was peer reviewed, so I don't feel as if we'd be living on the edge of we'd be releasing without an extra RC.My main concern is that of we're treating this issue as a semi blocker - it's almost unthinkable we won't find something of similar (small) magnitude in the next seven days. That's my only concern with releasing next week,m. Would people here again demand to delay, even if the impact is very limited - as is the case with this
count()issue? If it wasn't for that concern, I'd probably be in favor of delaying.
The main concern of many of us is that many people here seem to be
demonstrating a cavalier attitude around what constitutes a .0 release
(a stable release). Of course it's going to have bugs, but it MUST
be as stable as possible. The attitude by many here of "eih, it won't
be bug free anyway, so who cares" is poison.
If we delay further, we lose nothing. It's not like shipping a week
later is going to cost anyone anything. But shipping a broken version
WILL cost us a lot. We've been really good the past several releases
(5.4, 5.5, 5.6) about shipping stable versions day 1. If we break that
trend, it will shake faith. It will cost us far more.
Rasmus,
I think this was mostly a PR failure on my part actually. If I/we are a bit more careful about how we handle similar issues and the people lurking with itchy Twitter trigger fingers would spend a bit more time looking into the details we should all be able to get along and get a good launch with no controversy on Dec.3.
Sorry, but when you make a statement like:
Nobody is going to take a .0.0 and push it straight to production.
THAT is more than a PR failure. That's a perspective failure.
And it is not going to part of any sort of LTS distro either. It's not like LTS distros don't pick up point releases.
They don't. Debian squeeze is still pinned on 5.3.3. This causes me
major headaches since they didn't backport serious security features,
leading to problems today. Saying "they pick up point releases" may be
true for some, but the history is there that has caused MANY open
source projects a TON of pain. So it's definitely not something to
brush off.
I'm less concerned by the specific issue here than by the 2 facts that
surround it: It was known by engine maintainers for months, and the
cavalier attitude around what defines "stable". Both of these are far
more critical and worth delaying to "get right" than this particular
"bug" is...
Anthony
Hey:
On Mon, Nov 23, 2015 at 10:21 PM, Anthony Ferrara ircmaxell@gmail.com
wrote:
Zeev and all,
No one is expecting 0.0 or any version to be bug free, but the
simplicity of the fix says nothing about the seriousness of the bug. I
think it quite serious because we are a few days from GA, had this been
found a month ago it wouldn't seem so serious.No, but both the seriousness of the bug AND the simplicity of the fix
sit squarely outside any sort of "critical" definition.Perhaps, except that this bug was known by engine maintainers for
months. It actually took one of them saying it outright in a chat room
for me to be like "WTFBBQ" and raising this thread.That seriously shakes confidence in stability. What else is known but
not common knowledge? What else is not known? etc.The bug simply has the unfortunate connotation of being associated with
arrays, but is not - it's only aboutcount()ing symbol tables. The fix
itself is very localized too and was peer reviewed, so I don't feel as if
we'd be living on the edge of we'd be releasing without an extra RC.My main concern is that of we're treating this issue as a semi blocker -
it's almost unthinkable we won't find something of similar (small)
magnitude in the next seven days. That's my only concern with releasing
next week,m. Would people here again demand to delay, even if the impact
is very limited - as is the case with thiscount()issue? If it wasn't for
that concern, I'd probably be in favor of delaying.The main concern of many of us is that many people here seem to be
demonstrating a cavalier attitude around what constitutes a .0 release
(a stable release). Of course it's going to have bugs, but it MUST
be as stable as possible. The attitude by many here of "eih, it won't
be bug free anyway, so who cares" is poison.If we delay further, we lose nothing. It's not like shipping a week
later is going to cost anyone anything. But shipping a broken version
WILL cost us a lot. We've been really good the past several releases
(5.4, 5.5, 5.6) about shipping stable versions day 1. If we break that
trend, it will shake faith. It will cost us far more.Rasmus,
I think this was mostly a PR failure on my part actually. If I/we are a
bit more careful about how we handle similar issues and the people lurking
with itchy Twitter trigger fingers would spend a bit more time looking into
the details we should all be able to get along and get a good launch with
no controversy on Dec.3.Sorry, but when you make a statement like:
Nobody is going to take a .0.0 and push it straight to production.
THAT is more than a PR failure. That's a perspective failure.
And it is not going to part of any sort of LTS distro either. It's not
like LTS distros don't pick up point releases.They don't. Debian squeeze is still pinned on 5.3.3. This causes me
major headaches since they didn't backport serious security features,
leading to problems today. Saying "they pick up point releases" may be
true for some, but the history is there that has caused MANY open
source projects a TON of pain. So it's definitely not something to
brush off.I'm less concerned by the specific issue here than by the 2 facts that
surround it: It was known by engine maintainers for months, and the
I get a little confused, who said this was known months ago?
thanks
cavalier attitude around what defines "stable". Both of these are far
more critical and worth delaying to "get right" than this particular
"bug" is...Anthony
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Zeev and all,
No, but both the seriousness of the bug AND the simplicity of the fix sit squarely outside any sort of "critical" definition.
Perhaps, except that this bug was known by engine maintainers for
months. It actually took one of them saying it outright in a chat room
for me to be like "WTFBBQ" and raising this thread.
A conspiracy to hide a not-very-important bug that took minutes to fix would be a bit awkward. I have no idea who knew about it, but even if someone did, I can only imagine that the reason it wasn't disclosed was that they didn't think much of it. Whomever it was can shed light on this.
Either way, looks like we're creating some really negative vibes, questioning the very people who we owe gratitude for creating PHP 7, and in general, making an elephant out of a mouse. Let's go back to elePHPants.
My 2c.
Zeev
Zeev,
Zeev and all,
No, but both the seriousness of the bug AND the simplicity of the fix sit squarely outside any sort of "critical" definition.
Perhaps, except that this bug was known by engine maintainers for
months. It actually took one of them saying it outright in a chat room
for me to be like "WTFBBQ" and raising this thread.A conspiracy to hide a not-very-important bug that took minutes to fix would be a bit awkward. I have no idea who knew about it, but even if someone did, I can only imagine that the reason it wasn't disclosed was that they didn't think much of it. Whomever it was can shed light on this.
Conspiracy is a loaded term and not at all what I meant nor said. It
was known. And yes, I'm sure they didn't think much of it. That
doesn't mean that there aren't other cases where individuals made
tradeoffs that they feel are "worth it" but that others may not.
Considering this was definitely known in advance.
Causing one person to say "IS_INDIRECT is really kinda crappy, and
likely has many latent bugs. It sucks that things like count($array)
are no longer reliable but are now an upper-estimate" (SIC). That was
how I originally found out.
Heck Dmitry even admits it when he mentions that they had to work
around this very issue with serialize().
I'm not pointing fingers here. I'm not even saying people acted in bad
faith or anything remotely like that. I'm just saying that how many
other issues like this are waiting for us to find. Where people knew
about it but chose not to act because they "didn't think it was a big
deal" or "it wasn't worth the performance hit". And that's fine. But
at the same time it's concerning. And that's the point I was trying to
get across.
Either way, looks like we're creating some really negative vibes, questioning the very people who we owe gratitude for creating PHP 7, and in general, making an elephant out of a mouse. Let's go back to elePHPants.
Who's creating negative vibes? We're pointing out that we need to be
more clear around the definition of stable and the expectations for a
".0" release. If that's not being "grateful", then you're right we
shouldn't be grateful. We should be professional enough to talk about
our outcomes separate from the effort that got us there. We all are
incredibly grateful to everyone that put forth effort. But that
doesn't mean we should make compromises "just to ship something".
Anthony
Rasmus,
I think this was mostly a PR failure on my part actually. If I/we are a bit more careful about how we handle similar issues and the people lurking with itchy Twitter trigger fingers would spend a bit more time looking into the details we should all be able to get along and get a good launch with no controversy on Dec.3.
Sorry, but when you make a statement like:
Nobody is going to take a .0.0 and push it straight to production.
THAT is more than a PR failure. That's a perspective failure.
I still don't see anyone going straight to production with 7.0.0 unless they have been extensively testing the RCs. And if they have been extensively testing the RCs then any issues in them must not be impacting them. 7.0.0 is the wake up call for all the people who haven't been testing the RCs and as such it will generate more issues, regardless of how long we wait. That's why I still wouldn't suggest anyone go straight to production with 7.0.0 even if we delay another full year. This has nothing to do with being cavalier nor having a perspective failure about anything, it has to do with being realistic and pragmatic about how things work based on years of experience doing this.
Every single release in the history of PHP has been a compromise. We have RCs until the set of fixes from one RC to the next is free of major issues. There will always be more issues, so we have to make a release decision at some point.
-Rasmus
Rasmus,
I think this was mostly a PR failure on my part actually. If I/we are a bit more careful about how we handle similar issues and the people lurking with itchy Twitter trigger fingers would spend a bit more time looking into the details we should all be able to get along and get a good launch with no controversy on Dec.3.
Sorry, but when you make a statement like:
Nobody is going to take a .0.0 and push it straight to production.
THAT is more than a PR failure. That's a perspective failure.
I still don't see anyone going straight to production with 7.0.0 unless they have been extensively testing the RCs. And if they have been extensively testing the RCs then any issues in them must not be impacting them. 7.0.0 is the wake up call for all the people who haven't been testing the RCs and as such it will generate more issues, regardless of how long we wait. That's why I still wouldn't suggest anyone go straight to production with 7.0.0 even if we delay another full year. This has nothing to do with being cavalier nor having a perspective failure about anything, it has to do with being realistic and pragmatic about how things work based on years of experience doing this.
Every single release in the history of PHP has been a compromise. We have RCs until the set of fixes from one RC to the next is free of major issues. There will always be more issues, so we have to make a release decision at some point.
+1 on each and every word.
Zeev
Am 23.11.2015 um 15:52 schrieb Rasmus Lerdorf rasmus@lerdorf.com:
Rasmus,
I think this was mostly a PR failure on my part actually. If I/we are a bit more careful about how we handle similar issues and the people lurking with itchy Twitter trigger fingers would spend a bit more time looking into the details we should all be able to get along and get a good launch with no controversy on Dec.3.
Sorry, but when you make a statement like:
Nobody is going to take a .0.0 and push it straight to production.
THAT is more than a PR failure. That's a perspective failure.
I still don't see anyone going straight to production with 7.0.0 unless they have been extensively testing the RCs. And if they have been extensively testing the RCs then any issues in them must not be impacting them. 7.0.0 is the wake up call for all the people who haven't been testing the RCs and as such it will generate more issues, regardless of how long we wait. That's why I still wouldn't suggest anyone go straight to production with 7.0.0 even if we delay another full year. This has nothing to do with being cavalier nor having a perspective failure about anything, it has to do with being realistic and pragmatic about how things work based on years of experience doing this.
Every single release in the history of PHP has been a compromise. We have RCs until the set of fixes from one RC to the next is free of major issues. There will always be more issues, so we have to make a release decision at some point.
-Rasmus
I think every party has valid points and I think Rasmus is right. We'll always have some bugs where others think it's worthy a RC. I don't disagree with putting the bugfix into the 7.0.0 release (without further RC).
But after all it's affecting a rather edge case; just the symtables. I have yet to see code which would break without the fix. It wouldn't be too bad to have it in 7.0.1 now. It's not a PR failure. The only thing which harmed PR maybe is having put this up to public discussion, and then still...
But still, that's Anatol and Kalle who have to decide whether a further RC is necessary.
Please let's wait for their opinion now. Thanks,
Bob
The "There will always be bugs" argument is a strawman, nobody is
saying wait until it's perfect.People in this thread are consistently conflating "there will always
be bugs" with "lets just ignore this bug which is 'around critical'
and crack on because yolo."You seem to be confused Phil. Nobody is arguing that this bug shouldn't
be fixed. The question is all about how severe it is and whether it
should trigger another release candidate.-Rasmus
Thanks for replying Rasmus but I am not at all confused, and you
seemed to miss my point in the larger email. The one you replied to
was a reitteration as the sentiment was being repeated.
If this conversation was 100% about the severity of the bug, GREAT.
Instead, people keep saying nonsense like "Nobody will use 7.0.0" and
"Whatever we can just release 7.0.1 really soon." and ".0.0 releases
are just to get people to start using it."
Those arguments are AWFUL and I hate that you folks keep using them.
If you want to 100% discuss severity that would be great, but nobody
is doing that, and they're derailing with this absolute nonsense.
The conversation is STILL not about the severity of the bug, it's now
about playing the blame game of whose fault this is that PR got bad,
that people are being meanies to those that are working hard (not
true) and repeating the same mantra over and over again:
I still don't see anyone going straight to production with 7.0.0 unless they have been extensively testing the RCs.
That isn't what stable means. .0.0 means that everyone who's been
waiting for this gets to use it. Ever random Jane is going to grab
this and start developing with it, without ever seeing a single RC or
this thread.
Please, please, please PLEASE stop repeating this.
It sounds like a fix exists which people are happy with, and some
folks are ok not making another RC. Discuss that aspect. Do a little
poll on that. Do anything other than repeat these weird sentiments
about how people don't use stable releases over and over.
On Mon, Nov 23, 2015 at 12:23 PM, Phil Sturgeon pjsturgeon@gmail.com
wrote:
It sounds like a fix exists which people are happy with, and some
folks are ok not making another RC. Discuss that aspect. Do a little
poll on that.
Done. Here is a little poll:
Den 2015-11-23 kl. 08:28, skrev Anatol Belski:
Hi,
-----Original Message-----
From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Sunday, November 22, 2015 11:20 PM
To: Anthony Ferrara ircmaxell@gmail.com; Zeev Suraski zeev@zend.com
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] INDRECT in arrays causescount()to become
unpredictableZeev,
I think this is significant enough to be a blocker to gold and that
we should fix it prior to release.Thoughts?
IMHO, unless we think fixing this would require breaking binary compatibility
(which I don't think is the case) - this shouldn't block 7.0.0. 7.0.0 is a lot more
about getting people to start paying attention to 7.0 and start testing their
codebase against it - finding both the incompatibilities in their code and,
undoubtedly - the bugs we failed to find. I wish we could say this would be the
last issue we find in 7.0, but I think we can all agree it's wishful thinking...
Consider that Distros may very well pick whatever we call stable for
LTS releases. Meaning that non-critical (crash/security) bugs that we
miss may wind up living on for a VERY long time. If we don't intend .0
to be stable, then what's the point of versioning in the first place?Xinchen,
Very interesting on the fix. I do think it's important for this to
land with 7, but at least we can have the discussion.
I agree with Zeev here and I had a chat with Anatol about this tonight.
This is a .0.0 release. Nobody is going to take a .0.0 and push it straight to
production. And it is not going to part of any sort of LTS distro either. It's not like
LTS distros don't pick up point releases.
There is no way we will go 2 weeks without finding something for quite a while
still which can drag things out indefinitely. The question is whether this is
significant enough to postpone further. Personally I don't think it is. Let's get
7.0.0 out the door and get ourselves on track for regular point releases without
any of this "perfect-release"
stress.From what I was merging for 7.0.0, I see that there are quite some primitive bug fixes, a couple of non critical 7.0 bugs and 2 bugs merged up from 5.6. The issue with the symtable counter stands at some point around the critical border. I personally would see it as not crossing that border.
So based on this, I'd rather go by releasing. The bug list after RC7 looks pretty much like a regular patch release, or even better. Comparing to RC6 where it was started to be tested obviously some more intensively, RC7 looks more like lost attention. We could go with more RC, sure. However in that case IMO we would catch bugs at very low speed with no guarantee we have a good thing at the end when we "think" it's good. This will cause us to defer things for much longer time. Releasing on 26th (or on 3rd with respect to Thanksgiving, if there are still strong concerns) were IMHO convenient for this reasons.
People that don't test RC won't start to test any later RC anyway. People that don't test RC will start to use GA and that will lead to bug reports, in any case. So IMHO at this point we are good enough to do the first release with all the known bugs fixed, with the knowledge that no critical bugs are present, with the knowledge that community projects like Drupal 8, Symfony, etc. report the green tests, and with intention to get people waiting for GA involved.
Regards
Anatol
Hi,
To give some feedback on our needs for a GA release of 7.0 is:
- Having a GA out is a strong incentive for our ISP to deploy 7.0 on our
server.
I believe that they have done some work to integrate 7.0 in their
environment
but nothing is yet available for us as a customer. - Having 7.0 deployed on our server means we can start testing on the
server.
Of course we can spend time testing & porting on laptops but as long
as we
don't know when 7.0 is available we don't want to work to much in
advance. - I expect it would take 1 - 3 months to port our application to 7.0 and
given
that our ISP has maintenance windows once a month I would expect us to
deploy on a 7.0.x version. - A quality stamp for us that 7.0 is good enough is e.g. the passed
tests for
Drupal 8, which gives confidence.
So good luck with having a release out before christmas (3/12), you have all
done a terrific job! In Swedish I would call the coming 7.0 a
"Kioskvältare" :-)
Regards //Björn
PS Can add that our existing application would run in parallel on PHP 5.
Hey:
On Sun, Nov 22, 2015 at 6:47 AM, Anthony Ferrara ircmaxell@gmail.com
wrote:
All,
It appears that in our efforts to optimize PHP 7 we've introduced an
inconsistency into array handling. This is demonstrated by this
script: https://3v4l.org/hVcAB$a = 1;
unset($a);
var_dump(count($GLOBALS), $GLOBALS);The result is that the count doesn't match the contents of the array.
It also affects objects casted to arrays in certain cases.
Here, the array has 1 element, but should have 0. Trying to access the
"1" element "a" results in a notice.This means that the count is incorrect. This is due to the fact that
the "a" element follows an IS_INDIRECT type pointing to the other
symbol table.A potential solution would be to make
count()an O(n) operation in the
case that the hashtable is a symbol table or if it has INDIRECT
elements. Meaning that we'd compute the real count at runtime.This obviously has performance ramifications, but we shouldn't
sacrifice consistency and behavior for performance IMHO. Especially
when it comes to core data structures.I think this is significant enough to be a blocker to gold and that we
should fix it prior to release.
I don't think so, it's only affects symbol tables. means, it won't affects
normal arrays. like:
<?php
$array = range(1, 10);
unset($array[2]);
var_dump(count($array));
$array = array("foo" => 1, "bar" => 2, "dummy" => 3);
unset($array["bar"]);
var_dump(count($array));
?>
anyway, I've fixed this here:
https://github.com/php/php-src/commit/eada2aa91add2de69bc5783b840a21243a7b0678
and, we maybe move this new functions into zend_hash(as a ZEND_API),
anyway I am not sure whether it's okey for PHP-7.0.
will discuss with welting and Dmitry on Monday.
thanks
Thoughts?
Anthony
--
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hey:
On Sun, Nov 22, 2015 at 6:47 AM, Anthony Ferrara ircmaxell@gmail.com
wrote:All,
It appears that in our efforts to optimize PHP 7 we've introduced an
inconsistency into array handling. This is demonstrated by this
script: https://3v4l.org/hVcAB$a = 1;
unset($a);
var_dump(count($GLOBALS), $GLOBALS);The result is that the count doesn't match the contents of the array.
It also affects objects casted to arrays in certain cases.
Here, the array has 1 element, but should have 0. Trying to access the
"1" element "a" results in a notice.This means that the count is incorrect. This is due to the fact that
the "a" element follows an IS_INDIRECT type pointing to the other
symbol table.A potential solution would be to make
count()an O(n) operation in the
case that the hashtable is a symbol table or if it has INDIRECT
elements. Meaning that we'd compute the real count at runtime.This obviously has performance ramifications, but we shouldn't
sacrifice consistency and behavior for performance IMHO. Especially
when it comes to core data structures.I think this is significant enough to be a blocker to gold and that we
should fix it prior to release.I don't think so, it's only affects symbol tables. means, it won't affects
normal arrays. like:<?php
$array = range(1, 10);
unset($array[2]);
var_dump(count($array));$array = array("foo" => 1, "bar" => 2, "dummy" => 3);
unset($array["bar"]);
var_dump(count($array));
?>anyway, I've fixed this here:
https://github.com/php/php-src/commit/eada2aa91add2de69bc5783b840a21243a7b0678
and, we maybe move this new functions into zend_hash(as a ZEND_API),
anyway I am not sure whether it's okey for PHP-7.0.
The patch looks fine. We already use something similar for serialise().
Thanks. Dmitry.
will discuss with welting and Dmitry on Monday.
thanks
Thoughts?
Anthony
--
--
Xinchen Hui
@Laruence
http://www.laruence.com/