Re: On PEAR quality issues and natural selection

Some comments of mine, written about 58 messages back, but I think they still have merit. Klaus From: "Alexey Borzov" <borz_off@cs.msu.su> > Greetings, > > I had a "gut feeling" that something is not right with the PEAR QA team proposal > [1], but wasn't able to verbalize it. Fortunately I came across a nice > PEAR-bashing thread [2] in "PHP - Theory and Design" forum [3] which gave me a > lot of food for thought. So here's what's wrong: > > The proposal tries to address the symptoms of the problem (unfixed bugs) instead > of its cause. I'm sorry, Alexey. The QA Team is not about changing the PEAR community. That's what the PEAR Group is for. A QA team is for QA. And that has everything to do with bugfixes, etc. Please don't try to crash it because you don't understand what QA means. QA is all about fixing symptoms. If you want to fix the problems, write an RFC, like you say you will below. That's how to fix your kind of problems. > > 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. > > > 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. That is indeed a valid concern, and a big problem. But saying "we don't need a QA team" won't fix it. And even if maintainers would fix bugs within 5 minutes, there _still_ needs to be a QA process to ensure the quality of the code. Why do you think PHP has a QA team? Because they're sloppy? Nope. Because it's needed. And I don't hear anyone complain that the PHP QA team isn't needed. That would be stupid. > 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. Sorry, your pseudo-QA group won't solve all the problems that we have. We need people who are responsible. The QA team proposal will a) increase pressure on maintainers (you propose to solve that problem) b) ensure code quality c) prevent borked releases d) create a group of people who are _accountable_ for maintaining quality standards. Of course, you argue that b) will be given, and c) won't happen, and d) will be the maintainers. I disagree, however, that weakened ownership is necessarily the way to go. If I am maintaining a package, I would not like to see changes made that I dislike. You seem to think that it's a bad thing that Linus maintains ownership of the Linux kernel, and that only he and his leutenants can apply patches. To be honest, I believe that without a limited set of people feeling that they own a package, code quality will degrade and development will eventually stop. If the kernel doesn't need community maintainership and it is so large, why do you think that these small packages do? I agree that in a bunch of cases, people have misued the PEAR system. For example, I think that Sigma should never have been needed -- instead, it would have been best to encorporate the changes (in as far as possible) into a IT[X]2 release. There could always be an IT[X]3 release that would fix any problems with IT[X]2. Of course, some issues such as ereg vs. preg are not so minor as they seem. And if the maintainer wants to keep it the way it is and has a reason for it, so be it. Second example: Mail_Mime. I disagree that the existing package is sufficient, esp. when Richard (Hayes) has so little time for developing version 2. He also took the code out of the repository, effectively preventing anyone from seeing if he is even working on it at all. This was indeed a sad thing, and I'd have no problem with a second mime package, provided it fixes all the shortcomings of the current package. > Well, I am going to write an RFC for allowing competitive packages and publish > it via PEPr. Go ahead. But realize, that as the RFC author you can't force your viewpoint down everyone's throats. You have to accept and incorporate others' comments if you want your RFC to be successful. That aside, I'm happy you want to write an RFC. That's what the whole RFC system is about. It prevents long and pointless flamewars. And... anyone can do something constructive rather than simply criticizing. That's what's the problem with discussions like you linked. If the people really want to see a change, they can do something about it: write documentation, write RFCs, etc. Those who simply gripe will never be satisfied. It's always easier to tear down than build up. Klaus