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
this.
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.
eg.
Release branch 4.0.87
Showstoppers: #20457, #24099
Serious: #24, #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
to it.
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. :)
-Rasmus
--end of quote--
Cynic
--
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]
