Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89299
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.215.47 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <56523F74.9040708@lerdorf.com>
References: <CAAyV7nG9E-7STWq2Hpe=y5Uf0nWzGMhka+FUX1p1FVNtYNVTJQ@mail.gmail.com>
 <112FFBCD-8445-40BC-B92F-3A97D3E97C4C@zend.com> <CAAyV7nE0bQba3Wr2yi8FbtDfDA=8ZSFz9dbQG5uZ+eF9bick2A@mail.gmail.com>
 <56523F74.9040708@lerdorf.com>
Date: Sun, 22 Nov 2015 15:48:43 -0800
Message-ID: <CADajX4Bf7ycsPjbJYR_9UBFwQR6uFP1zVqmQZFCDwjq5rynmSg@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, Zeev Suraski <zeev@zend.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable
From: aharvey@php.net (Adam Harvey)

On 22 November 2015 at 14:19, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> On 11/22/2015 06:18 AM, Anthony Ferrara wrote:
>> Zeev,
>>
>> On Sat, Nov 21, 2015 at 11:52 PM, Zeev Suraski <zeev@zend.com> wrote:
>>>
>>> IMHO, unless we think fixing this would require breaking binary compati=
bility (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 incompatibilitie=
s in their code and, undoubtedly - the bugs we failed to find.  I wish we c=
ould say this would be the last issue we find in 7.0, but I think we can al=
l agree it's wishful thinking...

Sure, but not every issue is created equal. Not being able to trust
count() is pretty fundamental =E2=80=94 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 =E2=80=94
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