Re: On PEAR quality issues and natural selection

Alexey Borzov wrote:

Selkirk writes:

Another problem is that PEAR can't decide what it wants to be. Is it a library? Is it an application framework? Is it a loose collection of libraries? If you look at their five template implementations, you might think its a collection of libraries. Quickform implements validation, and so does a validation module. On the other hand, some attempt is made to have a cohesive whole.

Its a loose collection of libraries.

lastcraft adds:

Unfortunately there is real rot within PEAR culture and I don't see it being sorted out any time soon.

I wouldnt call it "rot" but changes in such a large project always take time.

The fundamental problem is that it doesn't really know what it is. If it was a public package repository (like CPAN) then it would at least have potential. The trouble is that in the hope of getting reuse they have instituted a dev discussion list in which you have to get 5 votes and duplication of function is not allowed. The result is that the first person to announce does a land grab on a package. It doesn't matter how good a follow up package is, it won't get in.

Very wrong. We encourage cooperation and aside from your run into Pierre we have managed to find solutions. Well actually Paul's DB_Table is another example, but I think both cases are not clear cut either way. We dont however disallow new approaches to solve issues existing packages already address.

The voting system doesn't help either. I had the dubious task of monitoring pear-dev and it was painful. The other attendees will give the most cursory look at an incoming package. They usually don't understand the objective, find some relatively minor piece of duplication and then reject it. Some excellent work has been rejected by this self appointed club. MDB is a superb package, but had a hell of a job getting because of DB (fortunately it did succeed, not helped by the original author).

Actually Stig was one of the main people who supported me. We are getting alot of proposals its kind of hard to expect every single one to be closely examined. However I dont agree that we dont look at new packages. Also we do ask about possible overlap and if I was to criticize the proposals we get then its the lack of awareness of what is there already. It makes it easier for us to look in detail at packages if people would write better proposals too. I think the PEPr system has improved the situation for all parties involved however.

To make matters worse unscrupulous owners can claim that a package actually falls under their own remit and they were going to release something anyway, again causing rejection. This is M$ style preannouncement. I have been a victim of this and I saw two other instances in three months. The only hope is usually to submit a nearby package and sneak something useful in under the banner.

This sounds like FUD to me. I am not aware of such issues (I wouldnt call the DB_Table issue an example of "unscrupulous" developers) so the person in question hasnt made a significant attempt at discussing the issue. I think I can rightfully claim that I know pretty well what has been going on an all PEAR lists in the past 12 months or so.

PEAR has this idiotic sheme because it also thinks it is a class library. Class libraries are not made this way, they are reworked by small talented groups. Class libraries are achieved by refinement and refactoring. You can only have refactoring with tests and shared ownership. That's when you get reuse and quality.

I dont think we have the ressources to have a few wise guys come up with all the code we have in PEAR. Sounds like a full time job .. you know the kind of job some of the Java folks have over at Sun.

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.

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?

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.

[2] http://forums.devnetwork.net/viewtopic.php?t=17235&start=15

I have replied to this thread. Most of the arguments are severely lacking imho. However I am one of the people that is very active in changing PEAR. So obviously I think that certain things need to be addressed in PEAR. So I am not claiming that PEAR is perfect at all. 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