Re: On PEAR quality issues and natural selection

Hans Lellelid wrote:

I just had to add my .02 here, since I've also felt pretty disappointed in PEAR. Sure, on one hand I don't contribute to PEAR & so I don't really have a right to complain. But on the other hand, PEAR does have a responsibility to represent the PHP community, and I'd say that the image PEAR portrays is not one I'm proud to be associated with in any way: it's one of fragile egos picking apart great contributions in the name of making things consistent with a vision that doesn't exist -- except apparently in the minds of the people rejecting proposals.

Are you sure this observation still holds true since the creation of the PEPr system?

Paul M Jones wrote:

A solution? Make PEAR a package manager/installer. Also a public repository in charge of namespaces. Insist on complete test coverage and documentation rather than rejecting on grounds of duplication. If a module became unpopular or has too many a bug, record this fact and make it public. Let the library self select.

http://forums.devnetwork.net/viewtopic.php?t=17235&start=15 (lastcraft, Sat Mar 06, 2004 2:50 pm) 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).

As I have stated in the forum and in another reply to this thread. We do alot competition. However we require that its not just a reimplemention that already exists with a slightly different API and a few features more or less. We require that it is actually different in how it tries to achieve the same thing.

I think this is absolutely a good idea and if PEAR doesn't do it, someone else will. ZZ/OSS is about to release a package installer that will provide for installing packages from remote systems; people will be able to create their own repositories of PHP apps or mirror existing repositories. This is a huge advantage over PEAR, because it truly makes package distribution a *community* affair. PEAR is anything but a community. All that's missing right now from ZZ/OSS is the commandline installer; I want to help build that using ideas from Phing,-- only wish I had more time.

I am sorry about the ZZ/OSS installer it simply no replacement. It doesnt handle PECL at all. It also doesnt have a command line interface. It does application handling very well. We will try to get there too. Channel support is being worked on as the next big step.

<rant> Why would anyone want to go through the minefield of egos on PEAR-DEV to get the PEAR stamp of approval when they can distribute their application using other means? I for one, have no idea what the "PEAR stamp of approval" adds to a package other than a stigma for bloat, crippling BC-requirements, over-rigid styleguide, soon a "big brother" QA team, and a very basic distribution system -- seemingly soon to be made a dinasaur by ZZ/OSS. Some of those are harsh words, but I have to say that I have also seen tons of great packages get rejected. I don't know what business PEAR has rejecting good work on the grounds of duplication, since clearly PEAR has little or no coherent vision for what it's class library should provide. (and that's just a re-iteration of that same sentiment expressed in the forum)

Wow that is harsh. However if you think that BC is BS then appearently you have a different vision indeed. if you think the QA team is the "big brother" then I can even less understand your reasoning. But I guess while PEAR strives to be for everyone, reality seems to tell me that it may strive towards this but it will not reach this goal. From all I have seen most proposals actually make it into PEAR.

Many tools like DB_OO and DB_Table are extremely useful (at least for a certain audience) and could have been made widely available to many people by now, but have not been because authors of other PEAR packages feel that they duplicated code or competed with existing packages. So what? To use a recent example, the Maketext package is certainly a ludicrous idea from a linguistics perspective, but I think it would also be really useful for people who wanted to translate within a language family (e.g. Indo-European) and so I definitely think that it should be allowed into PEAR. Afterall, it's a port of an existing (and apparently successful) Perl package. </rant>

This is a good example of where I would have hoped for the developers to cooperate with the developer instead. Alot of what these packages do overlaps with DataObjects. Of course they are different in some ways. But these differences could have been merged into DataObjects. Instead the developer chose to push their implementation. 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