Re: About PEAR site's package process

Just my 2cents As an old-timer, let me remind you of why some things are as they are. The rule of +5 to be accepted was a compromise to have packages that are not only well vetted, but also (in the opinion of the community) have enough general value and usefulness to be included in PEAR. The process borrows strongly from peer-review in science, and intended to not allow for a free-for-all repository like CPAN (the one example existing back in early 2000s). In CPAN it is difficult to separate supported well-written packages from weekend coding experiments, in PEAR that task is simpler for the end-user. Also, Docbook, back when it was being used for the PHP Documentation (late 90s, early 00s) was *the* format, I mean with that, that it was a format that allow is simple transformations to generate HTML, PDF, PDB (PalmPilot format), etc. PEARDOC inherited that. Back then, the other option could've been SGML or Latex, but those were not as maleable as XML. As for vendor repos. That is the very reason for the existence of channels. Each vendor can make its own. Also, the naming conventions (cumbersome as they are in PEAR) were used in a time where namespaces was something we wished but did not have, PEAR2 should use that to avoid naming collisions. Now I go back to the old-fart's cave and stop rambling :-) -- Jesus M. Castagnetto <jesus@castagnetto.com> Web: http://www.castagnetto.com/ On Tue, Dec 6, 2011 at 15:27, Vasil Rangelov <boen.robot@gmail.com> wrote: > > 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 > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >