Re: Forking PEAR

On Jul 15, 2004, at 9:17 AM, Heino H. Gehlsen wrote:

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

Disagreeing is fine (it's surely not the entire PEAR community which is becoming fragmented), but that still doesn't change the fact that any further development of the current PEAR repository will tighten the knot even more.

I don't think that PEAR should be for everyone. Is PECL for everyone ? no....

It will become even harder maintaining and supporting the PEAR project in the future, if a lot of the current problems are not solved as soon as possible. The current endless discussions proves to me, that some serious decisions have to be made, and considering some of the inexperienced opinions on this list I'd say, that every single opinion shouldn't always be taken into account at all times - perhaps people should simply keep quiet when they know not of what they speak (e.g. recent discussions about exceptions and protected)

I personally started to discuss about Exceptions before I knew anything about them. Each discussion among skilled and intelligent developers might often spring in a learning opportunity and this was certainly the case for me and many developers. The system is very democratic and that's what open source is all about.

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.

Hmmm, that's strange. Last time I checked the front page, it clearly stated that "PEAR is a framework and distribution system for reusable PHP components". In my opinion way too much is currently put under the same umbrella. Take the recent PEPr wote "Proposal for ProtectedMembers" for instance. If PEAR's primary focus isn't code, why were only people who had a developer account allowed to have influence on the coding standard. Currently one practically has to be a maintainer of a package to be taken seriously, and that package doesn't even have to be well maintained or more than a few hundred lines. Come on, PEAR is all about code. It is the same in PECL and any other official repository, to be taken seriously you first have to help the community in

a way or another. Is like being able to vote once you gain citizenship...

My original point was that too much time is spent on arguing, and most certainly on people who keep arguing based on way too fragile knowledge of what they are arguing about. PEAR is IMHO currently suffering from a typical open source symptom: Too many chefs reduce productivity to a minimum.

Sorry this is non sense. Mailing lists are opened and as such you can't decide what people should or should not argue about. Your statement is contradictory: first you don't want too many chefs then you want to limit the discussion on public mailing list under some unclear boundaries. If someone doesn't know a new concept like Exceptions (which is not even documented beside very little material like Zend) how is he supposed to learn without asking some questions ? (which at first might come out as naive)

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

Not really.

But one can't integrate something new and pure in a way too conservative old system without polluting it with a lot of the old stuff.

???

What you currently see (and saw in the last month) is the process of creating something new, without completly breaking the old.

What I'm currently seeing here is a lot of people who refuses to acknowledge that the current situation calls for tabula rasa, if we are to avoid the forthcoming mess.

Whilst I do respect your opinion, please don't pretend that your view reflect the majority ;) There is no forthcoming mess. Rules and standards are made to avoid the mess, not to create it. I don't believe in anarchy and we follow the same structure as the PHP project, there is a group etc. Try to go on Internals and tell them that their group is a mess and you want to add anything you like on PECL because is your visition...

snip

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 wasn't saying that PAER will break in front of the challenges. What I'm trying to say here is that way too much effort is wasted at the moment because of the illusion that one repository can fit the all (both users and PHP versions).

It can. We had PHP 5 only packages before PHP 5 went stable so we are really on a good sync.

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?

Sure we could start all over, and I could release a PHP5-only version of Net_NNTP, which didn't implement the same base interface as Net_POP3 etc., and we would once again and up with a repository containing a log of great packages which isn't designed to work together. We will suffer the same maintenance overhead in the current repository; we' ll just have to maintain multiple packages (different major versions of each package), when the PHP5-only packages kick in!

Well do you have any other way to have a package PHP 4 and PHP 5 E_STRICT at the same time ? If you do, let me know. There are a number of major changes from PHP 4 and PHP 5 and the straw man that because of that PEAR is not good enough doesn't make sense to me. The code should evolve and you should see this as an opportunity to enhance your package. You are also free not to do a PHP 5 version so is really up to you.

Those of us, who talk so fondly of PHP5-only packages, don't think that simply adding a dependency to "PHP ge 5.0.0" does the job; that's merely a package property.

Please don't try to mix your views with every PHP 5 developers sentiment. I, for one, don't agree with you.

What we foresee is a whole new situation where the new engine features will have a central role. What you foresee..

snip

Well, I've been working on large projects too, and I do agree that such dependencies are normal, but PHP is only a mere scripting language! I don't suppose that you leave it up to the users of your projects to figure out which versions to use? So we should perhaps even install the package for the user ? Sorry but I don't think PEAR is for people which are too lazy

to read the docs..

I'm not talking about throwing neither the installer nor the repository out of PEAR community! I'm talking about dividing PEAR into subprojects here. Having a base project containing the installer etc. and a number of subprojects handling different repositories etc. makes so much more sense to me than having one overly sized and totally unmanageable project. -10 for me

In the end of my initial email I actually martially proposed that the installer should become the heart of PEAR, and that the repositories should be moved into official PHP subprojects. why that ?

No more than pretty much every other open source project under the Apache Software Foundation umbrella. Does that mean that I have to participate in the PEAR debate club simply because I some time ago chose to become a PEAR maintainer? No way! Well feel free to unsubscribe if this is the case. I do apologizes if this came out as rude (and is not my intention)

but really I am somehow immune to the common argument "change PEAR or..."

Perhaps being both a central installation framework, a community/institution (with 1000nds of users), AND a (PHP4 based ;-) code repository at the same time is one of PEAR's major problems. PHP 5 just released a stable version two days ago.

Did you ever think, the Linux Kernel should be forked into

seperate projects for each major version?

Aren't the Linux Kernel forked into separate branches at each major release? No and you can't code for the Linux kernel unless you know what you are doing and listen to the "chefs".

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

Well, I guess it was kind of a joke;-) the acronym is fine, but perhaps the time has come for a reevaluation of what is stands for. I disagree.

Perhaps you are right, perhaps time has mutated PEAR into "The PHP Speakers Corner"; at least that's the impression I get, when I read the developers mailing list.

So your ideal project is a moderated mailing list where only things that you deem appropriate pass the check ? There is nothing wrong in using the mailing list as much as is necessary.

Perhaps PEAR has become more of a forum where users can seek help, when they can't figure out the API's of the non-evolving repository. PEAR has run into serious problems, and if we keep following the current path, the repository will end up a complete mess. That's your opinion but don't expect everyone to agree. If you want to help, start helping with packages orphaned and things like that.

Sorry but I started with Docs then doing things other developers didn't fancy that much so I don't think PEAR should be only about you and what you think but about the community.

One thing is for certain: Way too much time and effort is wasted in PEAR at the moment! Take Greg's Error_Stack for instance. People haven't even taken their time to study it, but they keep saying how bad it is at this and that.

Not true. It was a PHP 5 discussion and I trust you can find my points and the others clear enough.

Cheers David Costa