Re: On PEAR quality issues and natural selection

Hi! So, I feel it's time now for me to leave my 2 cents on this post. I saw a huge bunch of answers to it and I guess that very much of them are only answers to answers again, so they will be left for later reading. Anyway, first I would like to express, that it was necessary to state such a mail here, to let people rethink PEAR and maybe get up some constructive discussion, which can only improve it. Alexey Borzov said: > 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. I agree, that PEAR does not really clearify, what itself is. But why is that necessary? Some might want to use the PEAR classes as a framework, what is possible, because of a common error handling schema and in great parts a common API structure. PEAR clearly states, what it wants to provide. High quality open source components. That's all. Not more (framework, etc.) and not less (loosly class collection). > lastcraft adds: >> Unfortunately there is real rot within PEAR culture and I don't see it >> being >> sorted out any time soon. >> >> 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. I agree, that the "dublicate functions not allowed" rule has lived in PEAR too long and too agressive. The point should not be "do not allows duplicate functionality", but "do not allow duplicate functionality with the same approach". That's how the template engine category is working (mostly) today and that's the way PEAR is moving as you can see in the DB/MDB example. These are 2 great classes, having mainly the same idea in background (DB abstraction), but two really different approaches. PEAR isn't, does not and never did want to be CPAN. There are a few major points, which make the difference. PEAR trys to enforce a certain level of qaulity when a package is wanted to be added. True, that we sometimes were to rude in respect to duplicate functionality (see above), but the voting process (includíng esp. conditional votes), the initial developer comments, and most of the other practices have some kind of right to exist to keep a certain standard of quality. Therefor we have e.g. the coding standards, which are sometimes a pain for new developers, but nevertheless allow other devs to easily step into otherones code. >> 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). The voting system is nothing bad in it's roots. It's pretty usefull to show crappy developed packages where to go and childish developers, what the comunity (we, PEAR) thinks. Indeed, it's true, that the voting system sometimes (and more often in the last time) ended up to be a method of "I don't like you", "I don't like your package" or "Your package duplicates a certain functionality" statements, which is not it's sense. It's more like a missuse of a good tool. >> 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. >> >> 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 have to heavily disagree here. The means of PEAR is not just a "class library". PEAR packages should be usable on their own (except certain, usefull dependencies) but althoug in a bunch. A small dev group can handle a good class library, of cause, but this library will allways just cover parts of development and a developer would ever have to deal with several libraries for several functionality, bringing him several coding standards & styles, several documentations & doc types, several error handlings and stuff. The purpose of PEAR is to handle all types of classes under one hat and to give a developer a complete library of components he can use. I know, that these goals have still not been achieved by far, but we daily try to work towards them. > 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. I agree in some way. The opportunity to fix someone else's bugs is not really given. But for that, we are trying to bring up a QA team, which would be allowed to handle such fixes. A maintainer does not give a shit on yoúr fix? Send it to QA and it will be in the package within 7 days, promised. That would be the style I would like to have it. Same towards new package improvements. IMHO developers have to be forced to allow other maintainers to contribute. PEAR is not a political area, it's just for development. > 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. Right, we have. And what? IMHO to call PEAR a public package repository is the wrong way. Right, we have to allow more "dupes" in PEAR, but under the common sense of "different approaches". What gives you a collection of 10 DB abstraction layers following 3 differnt approaches? The sense of PEAR should still be to avoid dupes, but on a common basis of approaches to a problem. The way should be to loose the rule of "non duplicates" much more, but to keep it in mind. New packages which duplicate functionality must state, what the difference to existing ones is. An answer like "my method is named show() yours is named display()" would not be sufficient, but something like "my form package handles validation and stuff in one, yours is light weight and feature less" sound pretty good to me. In this case one has to secure, that the differences between packages get clearly stated on their websites and IMHO a comment system is needed by far. > 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. PFC have never been a way (IMHO), this only build up a "2 classes system" and thats never a good thing. The shared owner aspect sounds interessting to me, bu some kind of lead is pretty necessary. Or do you want every developer to be able to scump inside DB/MDB? > Well, I am going to write an RFC for allowing competitive packages and > publish > it via PEPr. Sorry, but I guess thats not the right time and way to do. I agree that changes in PEARs culture and ideal are necessary, but those have to get deeply discussed. My recommendation would be, to keep this topic up in the room and to get as much discussion and material as possible on it, merge that all together into a huge document of ideas, pros/cons and critics and have that discussed on the meeting in Amsterdam. After that, a PEPr proposal would have much more sense, since we can build up a clear structure (the topic "PEAR roadmap" is yet on the agenda) on what to change and how. Kind regards & happy easter everyone! Toby P.S.: I asked the PEAR users to give some hints on what to change in my blog, feel free to comment or just take a view: http://www.schlitt.info/applications/blog -- Tobias Schlitt a passion for php http://www.schlitt.info