Re: On PEAR quality issues and natural selection

Stefan Neufeind wrote:

On 9 Apr 2004 at 9:05, Paul M Jones wrote:

One of the forums has this to say:

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).

Especially about the "allow competitive packages"-part Alexey mentions I feel a little worried. Then we will end up like other class-collections are already, with the hundreds implementation. And this is imho one of the best features PEAR actually has.

True, very true. But the current situation isn't sustainable either. It leads to stagnation. See the state of the XML-RPC package for an example. It is just a pearification of Useful Inc's library, and had no feature additions ever since making it into PEAR. It's no secret that the fuel of open-source software is the pair ego/competition. There's enough ego here in pear. There's no competition, however. It's like trying to get a fire started with no oxygen. So, why not take the opportunity posed by the start of PEAR-QA to start a new era of PEAR? Pear has now sufficient visibility and critical mass to try and do two things: 1) Replicate the CPAN model. Relax the package acceptance rules, to basically contain code/test/documentation quality. Enforce these heavily. There's no excuse for a developer not to write good docs. 2) Fight complexity caused by over-numerous packages, by having PEAR-QA pick the best package per category. This should be done in a friendly dictatorship kind of way: selecting, say, the official DB package is prone for flame-war on lists, and would be extremely difficult to achieve a good solution on a mailing list. The process of replacing official packages should be laid out, but it can be done in the future. Cheers, Sérgio Carvalho

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc