Sent: Sunday, September 11, 2016 11:44 AM
To: Tony Marston
Cc: Stanislav Malyshev ; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickleSent: Saturday, September 10, 2016 7:47 PM
To: Tony Marston ; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickleThen I suggest that those who are so anxious to see of death of PEAR/PECL should be forced to provide a viable alternative first. Otherwise they would be just like those stupid politicians who try to force commuters out of their private cars and into public transport without realising that the existing public transport system is NOT a viable replacement and is incapable of taking on the extra load.
I just want to say that PEAR as a source repository, has been dead for quite some time. It's filled with outdated code that has hardly seen any maintenance in years, and nobody really contributes to it anyway.
PEAR/PECL as a package manager has historically had little utility to the average user apart from installing those PECL extensions which aren't packaged by a particular user's distribution repository. Certainly hasn't had any real viability in years. Trying to replace something that's inherently non-viable with a viable-alternative seems like a pretty moot point.
Just because you have found no use for it does not mean that others feel the same. How about those large numbers of websites that have to use PEAR Mailer instead of the built-in mail() function? I personally use SVNManager to manage my SVN repositories, and this is dependent on one of the PEAR modules, so there is a very recent use. How many other PEAR modules have been installed and are still is use? Do you have the download statistics for all the PEAR modules? That would be much more accurate that all this guesswork and supposition.
--
Tony Marston
On Mon, Sep 12, 2016 at 9:32 AM, Tony Marston tonymarston@hotmail.com
wrote:
Sent: Sunday, September 11, 2016 11:44 AM
To: Tony Marston
Cc: Stanislav Malyshev ; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with
composer/pickleOn Sun, Sep 11, 2016 at 4:47 AM, Tony Marston tonymarston@hotmail.com
wrote:Sent: Saturday, September 10, 2016 7:47 PM
To: Tony Marston ; internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with
composer/pickleThen I suggest that those who are so anxious to see of death of PEAR/PECL
should be forced to provide a viable alternative first. Otherwise they
would be just like those stupid politicians who try to force commuters out
of their private cars and into public transport without realising that the
existing public transport system is NOT a viable replacement and is
incapable of taking on the extra load.I just want to say that PEAR as a source repository, has been dead for
quite some time. It's filled with outdated code that has hardly seen any
maintenance in years, and nobody really contributes to it anyway.PEAR/PECL as a package manager has historically had little utility to the
average user apart from installing those PECL extensions which aren't
packaged by a particular user's distribution repository. Certainly hasn't
had any real viability in years. Trying to replace something that's
inherently non-viable with a viable-alternative seems like a pretty moot
point.Just because you have found no use for it does not mean that others feel
the same. How about those large numbers of websites that have to use PEAR
Mailer instead of the built-inmail()function? I personally use SVNManager
to manage my SVN repositories, and this is dependent on one of the PEAR
modules, so there is a very recent use. How many other PEAR modules have
been installed and are still is use? Do you have the download statistics
for all the PEAR modules? That would be much more accurate that all this
guesswork and supposition.--
Tony Marston
we have download statistics for pear/pecl:
http://pecl.php.net/package-stats.php
http://pear.php.net/package-stats.php
but it would be better to filter the stats to a more recent time interval
like last year or something, not sure if that is possible with the current
web interface, but you can see the recent download stats on the package
page, eg:
http://pecl.php.net/package-stats.php?cid=33&pid=876
http://pear.php.net/package-stats.php?pid=14&cid=19
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu