Re: On PEAR quality issues and natural selection

On 9 Apr 2004 at 9:05, Paul M Jones wrote: > One of the forums has this to say: > > > A solution? Make PEAR a package manager/installer. Also a public > > repository in charge of namespaces. Insist on complete test coverage > > and documentation rather than rejecting on grounds of duplication. If > > a module became unpopular or has too many a bug, record this fact and > > make it public. Let the library self select. > > http://forums.devnetwork.net/viewtopic.php?t=17235&start=15 > > (lastcraft, Sat Mar 06, 2004 2:50 pm) > > I have to say I like this idea. It is, of course, a complete > re-purposing of the PEAR ideal. But it would open up both the > competitive fronts while at the same time retaining quality standards > (coding standards, documentation, etc). Especially about the "allow competitive packages"-part Alexey mentions I feel a little worried. Then we will end up like other class-collections are already, with the hundreds implementation. And this is imho one of the best features PEAR actually has. What Alexey imho outlines correctly is that we need a more formalised way for handling bug-fixes and feature-additions. There are several bug-fixes and feature-additions in the bug-system where the package- leads have not at least taken notice from for a *long* time. So maybe we should define a certain time-range and after that (including a reminder again etc.) bug-fix the package by force for the good of PEAR. It's no use imho to branch off a complete new package. However, this is already on the to-do-list for PEAR QA. I'm a bit disappointed that so many people seem to dislike or mis-trust PEAR QA. It would make more sense to help doing the hard work thats needed to establish commonly agreed standards, so that PEAR QA can act according to them. I am very sure that on the PEAR-meeting in Amsterdam we can discuss a lot of the important points more easily, especially set the needed ruleset for PEAR QA, and announce an official QA-team shortly afterwards. As soon as the rules for fixing long standing bugs in someone else's packages has been set, PEAR QA can actively work on lowering the number of open entries in the bug-database drastically. That having said, I'd like everybody to wait until after the PHP Conference in Amsterdam, which will be at the beginning of May, and on the outcome of the PEAR QA process. Stefan