This is why I allowed important features in despite the feature freeze. However, it doesn't mean that unimportant stuff should go in as much as people want because otherwise we can't make a good release. I don't think open-source is about adding every single feature at any single point of time. The result would be horrible instability (not that I think your patch fits into this category I'm just saying that even open-source projects need some care).
Anyway, due to your patch being pretty much self-contained I thought it wouldn't be a big deal to introduce it. However, thinking it over, I don't think it's a crucial enough patch to force it in. I doubt you see it this way too. What's another 3-4 months going to do? People managed without it up to now.


Andi


At 11:27 AM 5/17/2004 -0700, Andrei Zmievski wrote:
On Mon, 17 May 2004, Andrei Zmievski wrote:
> On Mon, 17 May 2004, Sara Golemon wrote:
> > Sure it's been inconsistently applied, but that doesn't mean that striving
> > for consistency is inherently bad. It's especially "not bad" when the
> > initial implementation of the exception in question is incompatable with one
> > of the officially recommended set of build tools (bison 1.75 -- see:
> > http://www.php.net/anoncvs.php ) and breaks the Win32 snap generation.
> > Granted that's a minor bug, but it's a perfect illustration of why a feature
> > freeze exists.
>
> There is no such thing as a feature freeze in PHP land, historically.
> And that minor bug has already been fixed.


Let me add to this: isn't this what "open source" is about? The bug did
not manifest itself on my system (FreeBSD). You pointed out the issue. I
fixed it. Cooperation prevailed. What's the big deal?

- Andrei

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php



Reply via email to