PHP 4.0 Bug #10084 Updated: Release Quality
| From: | rasmus@php.net | Date: | Sat, 31 Mar 2001 08:17:32 +0000 |
| Subject: | PHP 4.0 Bug #10084 Updated: Release Quality | ||
| Groups: | php.dev | ||
| Request: | Send a blank email to php-dev+get-50401@lists.php.net to get a copy of this message | ||
ID: 10084
Updated by: rasmus
Reported By: augustz@bigfoot.com
Old-Status: Open
Status: Closed
Bug Type: Feature/Change Request
Assigned To:
Comments:
And I assume you will be pitching in and helping out on each front? We don't set out to have a
buggy release. There is a QA team and a QA process for this purpose. Feel free to join it. See http://qa.php.net
Compiling for command-line is trivial. Just don't add --with-apxs ot --with-apache and you
have the standalone parser.
And your bluesky stuff about adding bloat numbers to the manual. Go for it. That just takes
someone sitting down and writing down the numbers. You are more than qualified and more than
welcome to do this. Note however that this will be different on most platforms, so be sure to do
each one. Might even have significant differences across versions of the same operating system,
linkers, compilers, libc's, different versions of the 3rd party libs, etc.
Previous Comments:
---------------------------------------------------------------------------
[2001-03-31 00:02:29] augustz@bigfoot.com
As a happy user of PHP I'd love it if
a) Releases (4.0.5) could be installed across server farms, compiled to commandline versions to
support shell/console scripting, packaged in various ways for different workloads (ie adding IMAP)
without the sinking fear that in a few days to a week or two I'll see pl1, pl2, pl3 and have to
go through the who rigamarole again. So fewer patches, more RC's :)
b) Extensions that are broken do not ship with the distribution. The quality of the extensions
reflects on php itself. A few always seem to be borked but live on through releases. The folks that
want to fix borked extensions can probably do so even if they are not included in the distro. Hand
in hand with that is at least keeping a rough idea (or requiring the submitter to) on keeping up to
date with extensions, which often are based on evolving external libraries and projects.
c) Bluesky: Bloat numbers on the manual for the different extensions. This contibutes x bytes to
cgi/apache module or whatever...
---------------------------------------------------------------------------
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10084&edit=2