Re: On PEAR quality issues and natural selection

From: Date: Fri, 09 Apr 2004 15:43:04 +0000
Subject: Re: On PEAR quality issues and natural selection
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-27244@lists.php.net to get a copy of this message
Richard York wrote:
I have to say I like this idea. It is, of course, a complete re-purposing of the PEAR ideal. But it would open up both the competitive fronts while at the same time retaining quality standards (coding standards, documentation, etc).
After listening in on PEAR-DEV for the past few months I agree entirely, I feel that PEAR has entirely too much beauracracy. A great deal of it is counter-productive, IMO. This thread http://forums.devnetwork.net/viewtopic.php?t=17235&start=15 conveys everything I've been thinking about PEAR. I don't understand the necessity to have to "INSTALL" a package, a package should be installable from just downloading the package and placing it in a directory. How many people actually have command line
Then please do so. The necessary download buttons or on the package homepages.
access? I don't, my ISP doesn't allow it. Then, whenever I want to use a PEAR package on my live server I have to manually alter each file. Packages should be completely portable, independent of the PEAR infastructure. Though after actually figuring how to use the PEAR infastructure, I thought it was quite handy, but its still useless to me since I can only use it on the development side. (If there are better methods, they aren't documented)
Well some people find dependency handling useful. Some people also find it useful to have an easy way to compile PECL packages. Anyways I dont use the PEAR installer either. But its funny you are complaing about an optional feature, that you are not paying for.
And I don't understand the point of the centralized error handling packages. I feel this further obfuscates things. I'd rather each package address its own error handling, and use PEAR error packages if the designer feels the need to.
I actually like it alot and it opens up alot of potential. The big issue is probably that its not well documented. And this is a real issue. This article may help: http://phpmag.net/itr/online_artikel/psecom,id,330,nodeid,114.html
The documentation on PEAR itself is difficult to navigate and confusing. The documentation assumes too much knowledge of the reader, even of an experienced developer.
Then help. We have very little arm raising in this respect.
In addition to the points raised in these articles about competitive packages, I think, IMO, this is what's holding PEAR back from true greatness. Survival of the fittest, IMO, variations of the same ideal aren't always a bad thing. And in the end, let the public decide anyway!
True we are not taking this approach. We are hoping cooperation could also work.
Documentation on documentation is another lacking area of PEAR, there's a link to the docbook website, but no explaination of how to write the bloody documentation, nor of how to access CVS and place it in CVS. You can get a CVS account, but no explaination of how to use it. No examples of well formed docbook xml, PHPDcoumentor is good, but its not PHPDocumentors job to explain how to add code snippets and tables and all that.
Sorry your attitude sucks. Its not that I am unwilling to write documentation. I spend alot of time on PEAR. But I can only spend this much on PEAR. The same applies to alot of developers. Few users have taken the time to write documentation after getting help on one of the lists. We have gotten really few contributions, btw the pear-doc team accepts plain text docs.
Some policing, code structure guidelines and whatnot are necessary, but all the beauracracy isn't. High quality code, certainly, but all the childish regulations and whining has got to go.
Err whining? I guess you are not interested in cooperation so why bother with joining a community? I mean why not go to phpclasses if all you want is a place to upload and then compete via survival of the fittest? I dont get it honestly.
I also feel the code structuring guidelines should be expanded to include the one true brace convention, on all control structures, not just functions... this other convention is difficult to read and most professionals don't use it (at least none that I've encountered).
WTF? so now you want more beauracracy? I am shocked with all of these comments. I am sure there must be ways to critize PEAR in coherent ways. But it seems you guys are jumping from one argument to another. There is one theme to all of this: very little interest in cooperation. This however is an assumption made inside PEAR. Maybe this is naiv. regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07

« previous php.pear.dev (#27244) next »