Re: About PEAR site's package process

> 1. remove the proposal process and let packages can be review or rating. > (let the packages be eliminated through selection and contest) There is a fine balancing act that needs to be made here... quality vs. quantity. Lesser quality control can easily lead to packages of poor quality, which would still be OK if all packages were not for the same thing... but if there were for example several Mail and/or DB abstraction packages in PEAR, it would soon become confusing for users which one is the most mature, especially if the APIs are similar. The situation in PEAR currently is not the same in that the reccomended package is clearly labeled (e.g. PEAR_MDB2 over PEAR_DB). Ratings don't really reflect feature set or quality... they reflect popularity, which is not directly reflected by those two. There are multiple open source hosting services (SourceForge, Github, Google code, etc.) in which people can easily filter based on the language. Some (I know SourceForge for a fact) even have ratings. The difference between them and PEAR is exactly that there is a centralized quality control at PEAR. > 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) As Brett pointed out, this is being done in PEAR2, at least for release notes and change logs. There are no tutorials for PEAR2 packages yet (not on pear2.php.net at least), but this will come as soon as someone can make PhpDocumentor or another similar application (e.g. DocBlox) support such formats (i.e. support linking between API docs and tutorials). > 3. provide tester for reviewing package quality. I'm not sure I get this suggestion... there's PHPUnit that lets developers automate testing of their packages... the problem is not all developers use it. In PEAR, having PHPUnit is not required (although reccomended, and if present is sure to guarantee votes). In PEAR2, having a test suite with 50%+ coverage is required to get a "beta" status (not for alpha releases). This is done in order to lower the barrier of entry. If you're talking about a human tester verifying the package quality... that's part of the review process. > 4. quality testing, use phpcs PHP_CodeSniffer to detect violations of a > defined coding standard. This is already being done, and is encouraged in the coding standards guide to be done by developers themselves before submission. Not everyone uses it of course, hence the review process. I think the only part that needs improvement is in just one rule of the voting process - the less than 5 vote denial rule... many packages don't get 5 votes, but get fewer positive ones. I think those should be considered accepted instead of denied. The other part is in the package.xml generation, but that's been taken care of by yourself and by PEAR2's dev tools. 2011/12/6 Lin Yo-An <cornelius.howl@gmail.com>: > 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. > > Once the process is improved, people will come to PEAR to release their > packages more and more. > > There are many good references for this, like CPAN, or RubyGems. > > CPAN: http://search.cpan.org/ > RubyDoc: http://rubydoc.info/gems , > http://rubydoc.info/gems/abcrunch/0.0.5/frames > RubyGems:  http://rubygems.org/ > > > Thanks :-) > > > -- > Best Regards, > > Yo-An Lin > > http://github.com/c9s