Re: On PEAR quality issues and natural selection

Alexey Borzov wrote:

The solution: be honest and call the current PEAR a public package repository, remove the "no competitive packages" rule. The rule was not strictly enforced anyway: we have 2 DB abstraction layers, 5 template packages, 3 form handling packages and so on.

This would only work if there are two levels on pearweb - the non-stable packages, and the stable packages, which is different from PFC, but that is a detail.

Sometime after this "PEAR The Class Library" (PEAR Foundation Classes, PEAR2, whatever) can be created. The packages will be accepted into it from base PEAR on author's request, if they conform to a defined set of rules (stable status, fully documented and having a full test suite).

This can be summed up with "low barrier to entry, high barrier to stability"

The package ownership in this library will be shared (so the author loses some exclusive rights) among the developers who have the packages in the library --- thus an automatically created QA group of competent developers.

This will take time to implement, and I think the QA group is a step in the right direction. PEAR's biggest administrative problem has been ego. I don't mean to say the old beef that developers have been too childish - on the contrary, the definition of who owns a package is too vague, and does not assume problems will arise. When designing a new political approach, this is the only way to proceed. Think of it as test-driven administration, or learning from history. "QA group of competent developers" <-- define competent. How is it measured? By the opinions of peers. All developers by definition spend a lot of time developing their own packages. I don't have time to do a serious review of everyone else's proposed packages unless they provide unit tests and documentation. Even then, I usually can't take the time to install and run them. So, unless people spend all of their time reviewing new packages, we can't possibly hope to solve the "gee that duplicates stuff" problem. Voting on the list tends to follow a pattern: everyone waits to see what the big guns will vote, and then follows suit. This is natural because of the previous problem. My point is this: if we don't even have time to properly review a package prior to including it PEAR, how in sam hill are we going to properly QA it after it's in? One part of the solution is to provide an automatic and consistent way to regression test packages. It is VERY important that we are not limited to using .phpt, phpunit, or any other testing framework, what is needed is a consistent API that is expected, so that the installer can run the tests with some degree of automation. As for entry, I think only the quality of code should be voted on. If a package is confusing, or seems poorly organized, it is fine to request that the author refactor prior to entry. The channels feature will be more than enough to allow other repositories to offer a low barrier to entry. PEAR should keeps its primary goal as providing only high-quality packages. In fact, I would be in favor of only allowing packages that have gone through a "farm team" system of testing, but that's for the future. Regards, Greg