At 07:35 25.4. 2001, Rasmus Lerdorf wrote the following:
>Nobody is talking about such an illusion. Let's not lose track of what
>caused this ruckus. A crash bug was found and fixed in a mainstream
>extension. It was just before a release. So the release was put off for
>a couple of days to get this fix in. I see absolutely nothing wrong with
I don't think the bug fix was the cause. It triggered the debate, but
the debate had been here before, and will return eventually. I remember
a very heated debate in IIRC about a year ago. A feature-freeze periods
were proposed, and dismissed. I think they should (and could) be employed.
I know it's not funny to clean up after oneself (or even others), but
other OS projects use stricter models than PHP does, and thrive.
I know you're subscribed to new-httpd@, do you think PHP group could
adopt some of their policies?
BTW, it's fun at times to watch new-httpd@ discussing the same things that
are discussed on php-qa@ and php-dev@.
>release branch, but here is where I would like the QA team or someone to
>step up and create a list of issues (likely just a list of bug id numbers)
>that they deem to be significant issues with the release branch. It
>should not be the QA team's job to track down developers and try to
>convince them to fix bugs.
>Release branch 4.0.87
> Showstoppers: #20457, #24099
> Serious: #245555, #354354, #546543
> Moderate: #535436, #45326543, #5443543
>Developers like finite-looking lists like this. They can see an end to
>the work. Fix 5 bugs and we are good to go for the release. Obviously
>there will still be bugs, but at least this would be an organized approach
This would be certainly nice, but for the moment the PHP 4 bug report being
sent to php-dev@ again (after a ... two months? pause) would suffice. :)
------end of quote------
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]