Re: The Nature of PEAR's Greatness

This seems like a therapy session to avoid entering depression because of the other thread ('On PEAR quality issues and natural selection'). For all the criticism that surfaced on the other thread, PEAR has lots of good aspects. I'd classify the criticism that appeared more as growing pains than as structural failure. All that is left, is learning and evolving. When evolving, don't loose the good aspects, improve on the bad ones. Stuff I'd hate to see disappear: - The installer: great command line interface, rather solid, non-interactive (much much better than CPAN's installer) - Peer code review upon package entry: This is excellent, and really creates a quality barrier to entry. Nobody wants to see PEAR become phpclasses when it comes to code quality. - Coding and design standards: Code looks the same accross packages, always follows sane conventions. Designs are always OO, with dependecies on other PEAR packages where necessary (there aren't many reinvented wheels hidden inside packages). - Last but certainly not least, the mailing list is quite sane. I've been following php-dev for half a year now, and I've seen no real flame wars or anything like that. Now, let's keep this, and try to correct the points mentioned. The single most important one is the relaxation of the no duplication rule for PEAR packages. Code and doc quality is way more important than non-duplication. Anyway, I don't believe there are that many high-quality packages for any given purpose. Let's focus on enforcing quality and maintenance efficiency. Cheers, P.S. This is my last post. I'm off skiing next week. See me down the slopes at Andorra :-) Sérgio

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