Re: On PEAR quality issues and natural selection

On Apr 9, 2004, at 5:32 PM, Lukas Smith wrote:

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?

I would agree with Lukas. The PEPr seems very fair to me. I also think that some PEAR potential developers might consider, if their package is rejected, to help with another package, bugs, documentation, examples or anything else. This is IMHO the right spirit.

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 don't think that opening duplication would make PEAR a better place. On the contrary will just confuse the users. Different API/features are a good ground to evaluate similar packages.

<snip>

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. I agree. Cooperating with an existing package isn't a bad idea, on the contrary I am sure that many developers are more then willing to open their package to more

concrete contributors. Regards, David Costa, Dotgeek.org

PHP-PostgreSQL Advocacy team     http://dotgeek.org

gurugeek att php dot net david at postgresql ddoot org $dsn = 'pgsql://world:most_advanced@localhost/open_source_database';