Re: On PEAR quality issues and natural selection

On 9 Apr 2004 at 23:44, Sérgio Carvalho wrote: > Stefan Neufeind wrote: > > On 9 Apr 2004 at 14:03, Hans Lellelid wrote: > > > > Yes, but the problem is that we try to prevent having too much > > orphaned, unmaintained packages which are maybe full of bugs or lack > > a lot of functionality. The fittest will survive - agreed! But the > > idea was that no package should be removed from PEAR (if possible) to > > maintain compatibility with any package or app that might have a de > > on that package - and therefor we can't allow 10 competing packages > > entering PEAR with only one or two surviving. Generally I get your > > idea - but such a step would imho be much counter-productive for PEAR > > in general, PEAR quality and PEAR reliablity in special. > > You can only prevent package death up to a certain point. Package > deprecation should be allowed. Granted, it's not good. It forces other > packages to rewrite code eventually so they can use new features. > However, it is sometimes a lesser evil. The greater evil, today, is > having a gradually stale package occupy territory and prevent other, > more efficient packages from providing the same function. Which packages in detail are you talking about? Name your suggestions for improvements, so they can be evaluated. PS: But maybe please wait a while till pear-dev is back to normal :-)) Yes, package deprecation is allowed. But we should imho not try to allow too much competition. It's no use if we have the fifth or tenth implementation of a package, simply because the coders did not even evaluate how their ideas could be integrated into existing packages. I've several times heared "I want to propose this package. I've used the source in a project of mine". That's fine - but those people sometimes even proposed things that already existed and maybe only one special function was missing in the existing package. So adding another package just for the sake of competition wouldn't have been good for PEAR in any respect in those cases. That having said: I'm very open to alternative implementations. However, I also strongly favor to see if those new ideas can be integrated without over-complicating things. Stefan