On Fri, 1 Feb 2008, Marcus Boerger wrote:
* Develop a PECL CLA that can optionally be used for PECL projects.
* If necessary, adapt the PHP License, so that it works nicely
together with the CLA.
* The projects that want a CLA can choose between the PHP License or
LGPL.
* Change the
On Sun, 3 Feb 2008, Steph Fox wrote:
Well thanks to a separate PEAR channel, we have all the infrastructure
easily setup to have a different place for users to pick up the code. Or
are you more concerned about the CVS, than the distribution of the
packages?
I don't have concerns
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (625 total including feature requests)
===[*Compile Issues]==
43389 Open configure ignoring --without-cdb flag
Hi,
Pierre Joye wrote:
Hi,
I think the biggest myths in this CLA discussion are:
The main realization was that the vendors could not co-operate with
each other on code without a CLA in place, and that some of them would
not be able to co-operate with the community without a CLA in place.
On Sat, 2 Feb 2008, Steph Fox wrote:
1) Distribution woes need to end. With the work Greg's been doing lately on
PHP_Archive/Phar, that's very close to being attainable now in the physical
'getting PECL'd extensions out to people' sense, but unless people are running
CLI or CGI or have access
On Sun, 3 Feb 2008, Steph Fox wrote:
Everything else - the fashionistas (JSON, xmlreader/writer) and the downright
useful for some but not all (fileinfo, json, com_dotnet, posix) and the quirky
stuff (pretty much anything Sara came up with) - should be in PECL.
I see another issue after
I'd like everything in PECL. Even the core. And yes, it is quite doable.
--Jani
On Sun, 2008-02-03 at 00:21 +0100, Marcus Boerger wrote:
Hello Steph,
what I want is php-src as minimum you can depend on. And php-default as
release managers playground. The RM can then say what he thinks is
On Sun, 2008-02-03 at 10:56 +0100, Lukas Kahwe Smith wrote:
I am also not sure if including mysqlnd in PHP core is the way to go.
However I would not be generally opposed to including it in the PHP
distribution.
There's a technical reason for that: It needs to be statically buildin
to work
At 04:33 AM 2/4/2008, Derick Rethans wrote:
On Sun, 3 Feb 2008, Steph Fox wrote:
Everything else - the fashionistas (JSON, xmlreader/writer) and
the downright
useful for some but not all (fileinfo, json, com_dotnet, posix)
and the quirky
stuff (pretty much anything Sara came up with) -
PHP 6 Bug Database summary - http://bugs.php.net
Num Status Summary (61 total including feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
On 04.02.2008, at 11:38, Marcus Boerger wrote:
Hello Ben,
None of this is necessary though. What I proposed was moving
extension
development from php-src to PECL an dthen bundle what we see fit
into the
distribution just as we do now, whith the RM having the last say
what goes
in and
Hello Ben,
None of this is necessary though. What I proposed was moving extension
development from php-src to PECL an dthen bundle what we see fit into the
distribution just as we do now, whith the RM having the last say what goes
in and what not. In my proposal we would only put stuff into
hi steph,
well, i'm trying to use apache's mod vhost_alias, which doesn't allow to use
e.g.
php_admin_value open_basedir /some/path/%2
...which means that %2 is usually replaced with a part of the requested URI,
but that does not work, such variables like %2 are interpreded for
On Mon, 2008-02-04 at 14:23 +, ehl lhe wrote:
Perhaps you should look into PHP 5.3 which has a lot better support for
per-host/per-dir php.ini values. In 5.3 you can specify stuff in the
global php.ini file with special sections which only affect the certain
host / directory and those can
Perhaps you should look into PHP 5.3 which has a lot better support for
per-host/per-dir php.ini values. In 5.3 you can specify stuff in the
global php.ini file with special sections which only affect the certain
host / directory and those can not be overwritten anywhere.
Also there's the user.ini
Perhaps you should look into PHP 5.3 which has a lot better support for
per-host/per-dir php.ini values. In 5.3 you can specify stuff in the
global php.ini file with special sections which only affect the certain
host / directory and those can not be overwritten anywhere.
Also there's the
Hi Derick,
I see another issue after reading this, and that is that it makes it
much harder for users to depend on specific extensions just being always
available by default. It's important for application distributers to
have this core set of extensions to rely on. It's annoying enough that
Steph Fox wrote:
Hi Derick,
I see another issue after reading this, and that is that it makes it
much harder for users to depend on specific extensions just being always
available by default. It's important for application distributers to
have this core set of extensions to rely on. It's
18 matches
Mail list logo
