Re: Forking PEAR

From: "Tobias Schlitt" <tobias@schlitt.info> > 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". 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. 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) > > 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. 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. > > 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". 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. The content of the current code repository aren't worth the effort. While indeed a lot of the code is actually quite well done, it's by no means well integrated, and sadly a lot of code have IMHO become stable way too quickly (there is a general tendency to start at alpha state in stead of development state). > > 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 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). > > 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! 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. What we foresee is a whole new situation where the new engine features will have a central role. > > 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?? Of cause not in the current repository/channel, but any future packages should. The subject has been brought up a few times before, and in my opinion PEAR should have taken the consequences long ago. > > 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. Well, weird is probably the wrong word here, but the point should be obvious though: the users are burdened with the need to know which versions that works on which PHP versions etc. > 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. 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? > 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.) Very bad example indeed. I suppose you support having both Winzip 8 & 9 installed at the same at the same time, and letting the users decide which version they want to do an extract in the pop-up menu ;-) > > 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) If I'm not mistaken, the IPv4 package would become IPv4_3 after two serious BC breaks, since the package should be forked at BC breaks, and thus the release would be e.g. IPv4_3-1.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. 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. 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. > Did you ever think about, that PEAR is not just an "open source > project", but an institution with 1000nds of users? 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! 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. > 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? > > 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. > > 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. Not feeling flamed what so ever. I was merely hoping to start a well toned thread in which people of the two wings wouldn't flame each other. > 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. 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. 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. 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. Personally I thought from the start that it was too PHP4'ish (and I really mean from the start - that's almost a year ago), and that I wouldn't like using it for exceptions. Greg has wasted so much time on explaining practically everything about the class, but people simply doesn't bother. As a result the implementation of channels is still not reality. Regards, Heino