Re: About PEAR site's package process

On Mon, Dec 5, 2011 at 11:49 PM, Lin Yo-An <cornelius.howl@gmail.com> wrote: > Hi folks, > > I am Yo-An Lin,  the author of Onion (PEAR package builder) > https://github.com/c9s/Onion. > > > Since from Perl, I noticed that there are not so many packages on > pear.php.net or even on pear2.php.net. > > Till now, there are about 600+ packages on pear.php.net, but there are more > than 100000+ modules and more than 9000 authors on the CPAN site of Perl. > the numbers are from <http://search.cpan.org/>. > > I found the main differences are: > > 1.  users can easily register account on CPAN, and upload their modules > easily and free, there are no proposal process to proof module authors > patience, and the modules can still can be reviewed, rating, given > comments, to improve the quality. > > 2.  to use a CPAN module is quite easy, you can review the api design from > the synopsis document section at the main page of package, then check if > it's good enough to use.   like this:   < > http://search.cpan.org/dist/Moose/lib/Moose.pm> the > Object-Oriented System. > > 3.  CPAN tester site, which tests all CPAN modules, and generate a matrix > test report (with different Perl versions and Platform), since PHP5.4 has > big improvements and changes, package testing on different languages and > platforms are very important.  < > http://www.cpantesters.org/distro/M/Moose.html#Moose-2.0401> > > And on PEAR site, if people want to upload a package, they have to post a > proposal for this, and keep waiting for a review or discussion for days or > weeks, this makes package uploading process longer. though this could > filter out some ugly packages. but most people will lose their patience, > and not going to upload new packages again. > > I deeply want to help the PHP PEAR ecosystem, I think there are 5 things > need to do: > > 1. remove the proposal process and let packages can be review or rating. > (let the packages be eliminated through selection and contest) > 2. pick up an easier document format like Markdown for describing synopsis > and tutorial, release note, change logs for packages. (keep the PHPDoc for > API reference) > 3. provide tester for reviewing package quality. > 4. quality testing, use phpcs PHP_CodeSniffer to detect  violations of a > defined coding standard. > 5. separate packages by vender names (this won't pollute global package > name), let people can define their dependencies with vendor names. This sounds exactly like PEAR2. What do you think of that? -- Brett Bieber