Am 05.06.2011 12:57, schrieb Pierre Joye:
> The last point is that pecl allows a much more flexible release
> management than the core will even do.
in theory
> So instead of doing some marketing/communication actions by bundling some
> known extensions, we should better promote pecl better.
not promote - MAINTAIN it better!
in fact most of PECL-extensions are a lucky game since
linux distributors has to find workarounds for rarely
maintained extensions and you can not be sure that
a extension can be compiled after a update of php
or some system-library and only if you have luck
a maintainer answers on a bug-report
_____________________
http://pecl.php.net/package/GDChart
dead, no longer maintained and it needed a message to this list to
get this confirmed by Ilia Alshanetsky, WTF - why is there no big
red hint "DO NOT USE IT" until now?
http://pecl.php.net/package/geoip - stable
2009-03-11
what about try if this works after new releases of the
library behind - with recent GeoIP-Versions php crashs
if "geoip_db_get_all_info" is called, and sorry but
after more than 2 years it is not the users hob reporting
everything necause lazy maintainers writing code once
and orphaning it
http://pecl.php.net/package/pecl_http/2.0.0dev1
coll, in th emiddle of 5.3 lifecycle a total incompatible
reqrite is started and hopefully no one has projects
relying on the pecl-extension
http://pecl.php.net/package/ssh2
was three years not maintained and could not compiled
with recent versions of libssh2 without some magic
patches from distributors
http://pecl.php.net/package/gnupg
did not work for threee years on fedora-systems
no anwser on bu-reports - so what do you do in such a case?
and you will tell us PECL is a relieable source for components
anybody is using in his projetcs? not really!
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc