Re: On PEAR quality issues and natural selection

Hi! Lukas Smith wrote:

Now, how does this relate to the unfixed bugs? Simple: package maintainers do not feel *pressed* to fix them and no one else is allowed to. If the maintainer knew that having a bug opened for too long (especially with a diff attached) will eventually result in a proposal of a forked package with this diff applied, he will be much faster in applying it. If he knew that failing to respond to feature requests will lead to another package appearing which implements this requests, he will be more willing to allow a new contributor to work on "his" package.

Actually I think that most developer take pride on your packages, but for some reason or another they havent had time to fix the bugs. Some people obviously take more "pride" or simply have more time. As such the QA team is there to help.

QA team can fix single bugs, indeed. But it cannot help with the packages that have poor design, spaghetti implementation or the like, and these packages will obviously have many bugs. The current rules prevent better designed and/or implemented packages from appearing. Thus I am not opposed to the idea of QA team, but it is not the *whole* solution.

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.

the two abstraction layers were created as it was clear that the new package would take about a year to mature. the template systems made it into pear before we started to enforce this rule vigourisly. However the 5 template systems have atleast 3 unique approachs. One of the redundant packages we have you and your persistence to thank for btw. IIRC we have two form handling packages which also have 2 different approaches. Make up your mind what do you want?

Here is the problem: right now the person proposing an extension to the current package functionality is in an inferior position to the package maintainer. The maintainer does not have any incentive to accept the proposal and/or help him integrate the new functionality. The risk of having (a probably better) competing package proposed may easily become such incentive. Proposing a new package will not mean that it will be accepted, of course. I think that the current proposal process works OK, and am not advocating removing it! :] My main point: a new contributor should not jump through hoops to prove that his package is "different enough" to propose it. Oh, and we have 3 form handling packages, there is also HTML_OOHForm which is available in CVS only and probably suffering from a severe case of bit-rot.

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

Shared ownership will be very hard to do in such a large repository. Actually with the package RFC we sort of have this already. It is simply expected that changes made to a given piece of code by someone else than the original maintainer needs to follow a certain workflow.

If you look closely at what I wrote, shared ownership is not intended for the whole repository. It will be for the packages submitted by their authors into this hypothetic Class Library. So there will be 2 possible approaches: 1) Natural selection for the packages in the "bigger" PEAR. 2) Artificial selection for the packages in the "smaller" PEAR. Let's just not have the situation with no selection at all.