Re: Forking PEAR

Hans Lellelid wrote: > Heino H. Gehlsen wrote: > > > > Part of the community is extremely > > conservative, and that's defiantly the way to go, when stability is an > > issue, but blindly forcing backward compatibility and too conservative is > > extremely counter productive, and it's defiantly a problem when only one > > repository/release exists and a new major language upgrade is breathing down > > our necks. > > I share the opinion that PEAR is too conservative. The reactionary > approach to PHP5 has been discouraging. And the general lack of > knowledge about PHP5 (which has been in various stages of beta release > for over a year) is simply staggering. I wouldn't say that PEAR as a whole is too conservative. The reason that all these talks of thousands of users and backward compatibility have been allowed to stall practically every progress, is probably the lack of an incubator and a free development channel. > For being a group intent on setting standards for PHP quality and usage, > the official opinions articulated by PEAR are lagging way behind. While I think being somewhat behind is generally a good thing when I t comes to stability, the current situation is shocking. > PEAR seems to care about novice PHP users and yet is an OO library > implementing many non-elementary design patterns; Again channels could solve this, since those of us, who would like a high quality repository with no nonsense gadgets could simply start make an actual alternative to PEAR's code repository. > and lastly, PEAR enforces coherence through naming & coding > standards, This has been part of PEAR since forever. > but thusfar ignores much larger coherence issues of package > interoperability and design. This is probably due to both the conservative attitude towards backwards compatibility and the fact that the individual lead 'owns' the package. > Of course that's very much a different discussion, but I think the > debates are as fervent as they are largely owing to this lack of > definition. If PEAR could just decide, for example, that it is a "set > of tools for novice PHP developers" then those of us trying to push > exception use would take our evangelism elsewhere. :) Nooo, Don't leave PEAR in the stone age ;-) > [.] and now that PHP have gotten features > > like interfaces etc., I think it's about time to reinvent the wheel. > > Absolutely. I think that interfaces have the potential to really change > what PEAR is. The loosely coupled components that would be made > possible by a collection of interfaces would make for a much greater > degree of code reuse accross the PHP community -- not just within PEAR. People are so interested in the coding standard etc., but how about defining a common set of interfaces. Now that PHP5.0.0 is finally released, we ought to have thought about more than exceptions!!! > I think it would be good to remove the installer. Make it just as easy > to install external/non-PEAR packages as it is to install PEAR packages. Not _remove_ the installer!!! Move the repository, and make it the default channel. > I think that apt is a good model for the final design, where anyone can > add their own sources and those sources can provide stable/testing/devel > channels. Perhaps that is exactly how it's designed. Having used Debian for years, not an eye is dry reading such works ;-) but seriously I'm not sure having stable/testing/devel channels is such a good idea. In PEAR we mark each release as being either stable, beta, alpha or devel, and that should be enough. Perhaps a PEAR incubator of alphaworks channel would be a great way of ensuring that only well designed and stable code gets into the primary PEAR channel? > Mostly, why *haven't* channels been implemented yet? Is it a matter of > needing more developers to contribute time? Is there a technical > limitation? Well, if I'm mistaken it's Greg, who does the channel coding, and quite a lot of his time has been wasted on misc. misunderstandings concerning PEAR_ErrorStack. > It seems PEAR needs a solution now because PHP5 is stable & > PEAR is just going to become a mess of PHP4/PHP5 packages (e.g. what > happens when someone backports Net_GeoIP to PHP4?....Net_GeoIP0? > Net_GeoIP2?). Ups! Hadn't thought about that. Regards, Heino