On Thursday, January 2, 2003, at 05:08 AM, John Coggeshall wrote:
I tend not to see this as the real issue. The bug system can be adapted to our needs as we see fit. The bigger issue is the QA team time, energy, and effort that can be expended to all these test scenarios. This type of decision though will have to be made by the PHP/QA team, and not really by PHP-DEV. If this is of concern to you (developers), I suggest you (developers) become active in the QA process.When it comes to bug reporting/fixing, perhaps it's feasible to completely separate bug reporting for each module from PHP itself? For example, if each module is maintained completely separately from PHP with it's own version # then there should also be a separate bug reporting system for bugs found with that module.
I really don't see this being an issue any different for PHP Developers than currently setup. Which is support only exists for the latest PHP engine (hence the "please try newer version" bug responses popularity).
Just remember the idea right now is to move things into PECL to get ready for an eventual version freedom from PHP, but that is not happening just yet. Stig Bakken has suggested this in the past, and you'll find it in archives, that this would be taking the first step towards, working out a lot of the bugs if found and getting the process to iron out.When I look at PECL, I envision a system where modules are completely separated from the PHP core. Each module and their maintainer(s) (whomever they are) deal with their own bugs for that module, modules have minnimum PHP core versions for which they work with, etc. We could make this easier by providing a source-forge type of cookie-cutter bug tracking system for each module, and perhaps by making the modules themselves clearly independent of PHP. I'd like to see a system for modules where what modules PHP uses is not defined at compile-time at all by a ./configure statement. Rather, what modules are being used are defined in some sort of configuration file (where the configuration parameters for those modules are also located) and the modules are loaded dynamically. I should be able to go download the GD module and stick it in a subdirectory of /usr/local/lib/php and then edit my modules.conf (or something) file:<module name="gd"> Allow_jpeg=true Allow_tiff=false </module>
Please realize this change also removes the PHP idea of anyone can fix/add/modify to an extension mantra, and forces it to a realm of per extension release manager/authority. While I like this idea (something I and few others have advocated for awhile), it takes a rather 94 degree turn from how PHP has been developed for the last few years.
But it also removes the need to worry about what is enabled by default :)
1) Faster and easier installations of PHPThis isn't necessarily the right track to take. Remember that Windows users do not have the need/use of a compiler on their local machines always. As such, a system for distributing a binary is required. This has been hashed out, and Stephen Esser was at one time working on implementing it. Please see the archives for more information about this.
By removing all of those compile-time ./configure options it will make
PHP much easier to compile and install. Problems with a single module at
compile-time won't stop a user from getting PHP running, and if there is
a problem when the module is dynamically loaded it will be easier to
figure out what's going wrong.
>---------------------------------------------------------------<
Dan Kalowsky "Thought I'd visit the club,
http://www.deadmime.org/~dank Got as far as the door."
[EMAIL PROTECTED] - "Don't Get Around Much Anymore",
[EMAIL PROTECTED] Ella Fitzgerald
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
