Re: On PEAR quality issues and natural selection

Hans Lellelid wrote:

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

Yes, absolutely. From my perspective PEPr has changed nothing about what gets accepted or rejected; (Do you think it has?) it's just made the process more systematic. It hasn't even changed who can vote, has it?

How many packages have been rejected since PEPr?

I guess I'm basing my criticism on the idea that PEAR is not an open community -- far from it. I do not see anything coherent about the libraries that PEAR provides and yet I see a lot of selectivity in what gets allowed to be part of PEAR. My suggestion is this: allow anything that meets basic documentation and code quality requirements to be part of PEAR.

We are an open community since we allow new developer to join if they provide something new. Of course you can consider us closed since determining if something is new is upto the existing community members.

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.

ZZ/OSS is not there yet, true. I mentioned that it's missing the CLI component, but it will get there -- and it will be better than PEAR's installer precisely because it is OPEN, because I can create a repository of DB-related PHP5 applications and other people can mirror them. This is a far superior idea (IMHO) to the controlled-repository model that PEAR provides.

Err? We are working to provide the same thing. So PEAR sucks because it doesnt have features which a package that lacks features that PEAR has will have in the future? Greg is working to implement channels this very moment. Sure we are a bit "slower" to add new features. But that is because we have other pressing features to implement (like PECL handling) and more importantly we cannot take the same riscs as the ZZ/OSS people when adding new features. Our image has been hurt alot by releasing new features that havent been scrutinized enough before. Hans I have a great deal of respect for you, but this is not your best day.

I didn't say BC was BS, but I did say that PEAR's BC requirements and recommendations are crippling. The idea that Daniel fixing an obvious bug in DB broke backwards compatibility is ludicrous. Why should he have to commit to sloppy API until next major release just because some developers made errors that happened to work with an older DB version? That's crippling code quality. That's more of a tangent to the topic, though.

Because its important for people to be able to type "pear upgrade foobar" without having to work though all the changes. The particular fix added no value beyond slapping people for sloppy code. As such I see the value as fairly limited compared to the fact that peoples code can now break which used to work before. 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