ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
back

PEAR, PECL .. where lies the future?

Its been a while since we had a nice flameware about the relevance of either project. Looking at the stats packages for PEAR and PECL (unfortunately not properly separated atm), we see that 15 million downloads has been passed. Back in february we have not reached 10 million yet. Of those 15 million it seems about 2 million have been produced by PECL, leaving 13 million to PEAR. As such it seems that PEAR alone is likely pulling in more than half a million downloads per month. Suffice it to say I think these are the number of a successful project. PECL also seems to be looking quite well, given that it has alot less packages and also considering that not that many people have the ability to integrate their extensions into their host setup.

But there is obviously room to improve. It seems to me that documentation and testing has picked up in PEAR, though its still not where it should be by any means. User contributions seem quite low though at the same time. PEAR QA is handling issues but more concentrated on particular issues rather than spanning across all packages. The PEAR group has become alot less vocal. Slightly less vocal than I had hoped in a few cases, but overall I do not think that they need to be quite as active as in the early days after its creation, where alot of direction was missing.

Where I am most dissapointed atm is that we still have not improved the documentation situation. The intention of my following comments are not meant to be an attack on the relevant teams though. Its all volunteer work. Anyways requests for help in PEAR doc often go unanswered for much longer than on other lists. Providing plain text or HTML docs and getting them converted to DocBook is a myth (again I hold no grudges, especially not to Dan who has done so much on the pdo docs) that is repeated often unfortunately. The comments feature seems to have dropped of the radar entirely and the wiki project seems a bit stalled as we ponder how to best integrate it into the rest of the site. I am starting to favor taking Text_Wiki, Text_Diff along with some code from yawiki (like the area map and history) and implementing our own wiki from scratch tightly integrated into the damblan library. I do not have to time to spearhead this effort, though I would be there to help plan and code.

As for the PEAR installer things seem to have gained momentum again and I think the relevant people are working together much better again. However it seems that the installer now has such a serious image problem within the PHP internals people that its quite hard to get them back on board to do the testing necessary to handle PECL packages, especially binary packages. However even on that front progress is made. Maybe its time we rename the installer command to something else. I think this would not just be a jedi mind trick to get internals more involved, but it would also solve alot of user confusion as the PEAR installer is increasingly just a means of distributing additional functionality for PHP installations that is quite separated from PEAR itself.

As for PECL it seems more and more packages that are getting moved to PECL. The large bulk of them due to being of little relevance to the vast majority of users. Often this also means there is no maintainer around anymore as well. While in the past this was often forgotten these days a move to PECL also results in actually making a release inside PECL of the given code so that users do not need to grab things from CVS. At the same time we are seeing more and more PECL packages making the move into internals. IIRC the first such packages was tidy. Nowadays pdo is probably the more prolific example. The recent fixes in the oci8 extension also seem to be first available through PECL before being merged into a stable PHP release. IMHO we should really move all but the most critical extensions into PECL and simply bundle the last stable release with the next PHP release. Obviously most maintainers will naturally try to provide a release just before the next RC or stable release. So there will still be an incentive to produce stable releases in somewhat regular intervals. However active maintainers would then have the opportunity to provide even more frequent updates.

Anyways I could go on for a while more on this topic but its time to stress test my comments feature: What do you guys think?

Before you can post a comment please solve the following captcha.
your name