Re: Forking PEAR

Hi Heino H. Gehlsen! On 07/14/04 16:52 you wrote:

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.

I disagree. The community does not get fragmented, it's getting harder. Harder by discussing their heads of. Harder by helping unexperienced people (like I was one) to understand. Harder by taking every single opinion into account. Harder by finding the most feasible solution for a "problem".

Way too much energy is wasted on battling opinions, energy which could have been used so much better had it been put into code.

PEAR is an open source project that does not only deal with code, it's about defining standards (which get accepted by a large variaty of other projects, open source and even more commercial). If you're unlucky with that, stay in coding and just keep an eye on what's really decided.

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.

It's the other way around. Instead of saying "we make something new, cause they made something new" we say "they made something new, let's integrate it". What you currently see (and saw in the last month) is the process of creating something new, without completly breaking the old.

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.

PEAR (and the far most of all other PHP related projects) never did a migration before. Most are to small to have seriouse issues. In that way, PEAR is unique. We will find our solutions for PHP5 and will have as many issues with PHP6, but we will be alive and not break in front of these challange.

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.

What prevents you from releasing a PHP5 only package? Is there anything? Surely you maybe have to fix some issues as rules for those packages grow, but since you will be unstable for a while, that's possible. Simply add a dependency to "PHP ge 5.0.0" and you're done. Why the overhead of maintaining several channels, if dependencies can do?

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.

So, every package has to change it's name??

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 ;-).

Can you explain to me, what is weired about that? That's just release management and you will find something similar in each and every project of the size of PEAR out in the streets. Believe me, I'm working on a 200 people project, which trys to migrate a complete infrastructure for 20000 users with more than 300 applications. Those dependencies are normal. And we are not trying to cloud this by adding another stage of releases, when we upgrade from Win2k to Win2003. (Win2000_Winzip and Win2003_Winzip instead of Winzip8 and and Winzip9?? - Bad example, but see: it's late here.)

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.

Can you please explain, what is weired on IPv4_3? (Btw. it's IPv4-3.0.0)

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).

I agree with you in some point here. The installer should be a seperat unit. But I disagree to throw it out of PEAR. What would you name it? php-install possbily? What about the hundrets of applications you break. Did you ever think about, that PEAR is not just an "open source project", but an institution with 1000nds of users? Did you ever think, the Linux Kernel should be forked into seperate projects for each major version?

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?

The name is weired, though. Just stay on the initial name "PHP Extension and Addon Repository" and you are fine. ;) (Sorry, I can only take that for a joke.)

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...

No further comment here.

Well, that's my thoughts of tonight.

PS Please consider this a mission statement, and not a wish for another flame war.

I'm no trying to flame you (hope, I did not). I'm just reacting on your thoughts with my ones. Maybe I'm totally wrong with that, but in my eyes, you did not understand in many ways, what PEAR is and what it has become for PHP. Regards, Toby -- Tobias Schlitt GPG Key: 0xA6529579 a passion for php http://www.schlitt.info Like to say "thank you"? - http://pear.php.net/wishlist.php/toby