Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89329
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nGmdK++fLUBFJdPDfCJeVCZTNP+xnJmw=-xk+ZEQEkqGQ@mail.gmail.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> <06a601d125c0$99d5cfd0$cd816f70$@belski.net>
 <CAL=_i_kArsu2JGYtdZBa-mah+k6DL-cCWtiX16mVcTsxH3WDrw@mail.gmail.com>
 <CABBJUpdTUwvdtK+uRc386R4pceocXCsSEd9s4bu4jvH87MD-8A@mail.gmail.com>
 <CABDNdAG84+cW9TohGbA2r0ik5=yrHVyAd5g2wk8dKRh=LeqvPQ@mail.gmail.com>
 <5652D782.40601@lerdorf.com> <F037E7ED-B9B0-47DD-9B42-4EEC2B267118@php.net>
 <EFB1D7E4-C594-4F15-A6A0-5D8344BA8F79@lerdorf.com> <CAMUwpuQ_1Nsyj3tV_=QZBnwQ6tq-iNegRX+9xYXOsQneNVd=sg@mail.gmail.com>
 <CAL=_i_nfhOwQ7Nvp_JCVHuz0m448Z0K03y5EuV4VKBP2Zu5Wng@mail.gmail.com>
 <14D843AC-792B-4537-8859-023B98127E7D@zend.com> <CAAyV7nGmdK++fLUBFJdPDfCJeVCZTNP+xnJmw=-xk+ZEQEkqGQ@mail.gmail.com>
Date: Mon, 23 Nov 2015 22:29:51 +0800
Message-ID: <CABBJUpcL5aps4ndcC7Y1-ysXzXDDp_XB5L7AJwuTxYHtnd+fHg@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Zeev Suraski <zeev@zend.com>, Joe Watkins <pthreads@pthreads.org>, Julien Pauli <jpauli@php.net>, 
	Rasmus Lerdorf <rasmus@lerdorf.com>, Derick Rethans <derick@php.net>, 
	Phil Sturgeon <pjsturgeon@gmail.com>, Anatol Belski <anatol.php@belski.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114505fe0cc81205253610ed
Subject: Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable
From: laruence@php.net (Xinchen Hui)

--001a114505fe0cc81205253610ed
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hey:

On Mon, Nov 23, 2015 at 10:21 PM, Anthony Ferrara <ircmaxell@gmail.com>
wrote:

> Zeev and all,
>
> On Mon, Nov 23, 2015 at 9:05 AM, Zeev Suraski <zeev@zend.com> wrote:
> >
> >
> >> On 23 =D7=91=D7=A0=D7=95=D7=91=D7=B3 2015, at 14:04, Joe Watkins <pthr=
eads@pthreads.org> wrote:
> >>
> >>
> >> 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 f=
or
> 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 lurkin=
g
> with itchy Twitter trigger fingers would spend a bit more time looking in=
to
> 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
>



--=20
Xinchen Hui
@Laruence
http://www.laruence.com/

--001a114505fe0cc81205253610ed--