Re: Forking PEAR

Heino, I for one think these are great ideas. There are some huge technical hurdles that will be argued will prevent this because nobody will want to do the work :) #1: pearweb needs a complete rewrite in order to support channels #2: pearweb needs a complete rewrite in order to support channels #3: you probably know what I'm going to say :) However, I have done some work on a modular server that would support the xml-rpc side of pearweb and would also support a simple html forms interface. The look of pearweb could be written into another driver that would allow this to work for separate channels. However, this is a LONG ways off from being finished, let along stable. Greg Heino H. Gehlsen wrote:

Hi People of PEAR ;-) During the summer I've been reading quite a lot of rather disturbing threads about on this list, and it's becoming more and more frustrating to see the PEAR community becoming more and more fragmented. Way too much energy is wasted on battling opinions, energy which could have been used so much better had it been put into code. 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. This is where PEAR is currently stuck with its one repository/channel; too much ancient compromises and bad decisions in the baggage to allow productivity (quite a lot of open source OS distributions have releases such as stable, testing, unstable and devel to solve this). The final nail in the coffin of the illusion that one repository would last forever is the release of PHP5.0.0. Seriously, who expects the current PEAR repository to outlive PHP6? Not I, that's for certain. I'd like to propose that PEAR should be forked into separate channels each time a new major version of the Zend engine is rolled out. With the upcoming channel feature this should be possible. This way we'd have separate repositories/channels, each embracing new features of the corresponding PHP version, but NOT features of any future major engine versions! Currently we would have two repositories: one PHP4/Zend1-compatible and one PHP5/Zend2-compatible. The former being the current well tested (and partially stable) repository, and the later being a new clean repository. Each channel/repository could even have its own coding standard, so that needed changes could be made without annoying those who prefer staying with the previous stable PHP version. To prevent the channels from not being able to coexist, we could use a different prefix (e.g. PEAR2_ & PEAR3_ or perhaps PE2_ & PE3_) for each channel/repository. One side effect of this would of cause be that PEAR could coexist with a lot of other repositories without 'namespace' conflicts, and PEAR would no longer interfere with non-repository code either (unless people should be dumb enough to prefix their code with PEAR-something ;-). Furthermore this way of forking wouldn't force us into confusing package versions each time new engine features were implemented. It looks like Mail_IMAP is already becoming Mail_IMAP2 (after only a couple of months! Perhaps we need some kind of requirements to prevent packages form 'maturing' to fast!). Following that pattern, two years from now I'd probably end up using Net_NNTP3, which depends on Mail_Mime7 and Net_Socket4 (each package being the first PHP6-only packages). Too weird if you ask me! It would be so much easier/cleaner figuring out that e.g. PEAR3_Net_NNTP, PEAR3_Mail_Mime and PEAR3_Net_Socket were meant to be together (3 of cause implies that PHP6 is based on Zend3 ;-). Personally I believe this is a win-win solution. PEAR started rather ungoverned, and a lot of (sorry to say this) crappy code came into the repository way to easily and the APIs were settled way to fast. In my opinion it's time to start over (using channels instead of wierd package version numbers such as "IPv4_3"), and now that PHP have gotten features like interfaces etc., I think it's about time to reinvent the wheel. A more controversial proposal would be that PEAR should be further forked. The installer should be totally separated from the current repository; it should be considered a part of PHP. No, I'm not on a major crusade here, since the proposal wouldn't affect the way anything is installed. Actually I 'm only proposing that the PEAR installer should be moved into a separate channel/repository (or rather that non Installer packages should be moved into a different channel/repository), and that the installer should be allowed to rely on 'external' packages (e.g. from the current repository/channel). Anyway (now that I have finally taken the time to share my thoughts), how about changing the name from "PEAR" (PHP Extension and Application Repository) into some thing else more appropriate. The extensions have moved into PECL, and what happened to the Applications? On the other hand, since PEAR is currently an installer and a code repository, moving/renaming the repository would leave us with the PEAR installer. Hmmm. The "PEAR Installer", which handles installation of Extensions, Applications and Repository packages... That might be it. Having a cross version "PEAR Installer" and a few official PHP repositories/channels; that might be the way to go... Well, that's my thoughts of tonight. Regards, Heino PS Please consider this a mission statement, and not a wish for another flame war.