Hey: On Mon, Nov 23, 2015 at 10:21 PM, Anthony Ferrara <ircmax...@gmail.com> wrote:
> Zeev and all, > > On Mon, Nov 23, 2015 at 9:05 AM, Zeev Suraski <z...@zend.com> wrote: > > > > > >> On 23 בנוב׳ 2015, at 14:04, Joe Watkins <pthre...@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 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/
