Re: move PEAR to PHP 5-only?

Hello Greg, GB> How do PEAR developers feel about moving PEAR 1.5 to PHP5-only? GB> PEAR 1.4.2 will be out shortly, with all pecl issues fixed, which works GB> in PHP 4.x just fine. GB> It would give me no end of pleasure to stop actively developing in PHP 4. The letter you have written is a perfect example of a more complex PEAR problem. If you are not afraid of reading one of those negative feedback letters here is an overview. The problem is divided in three parts: 1. PEAR, like "P" in PITA? (expressive part) 2. The problem of being adequate - PEAR look from outside (where we are) 3. Where do we want to go tomorrow? a. With all my respect, what do you want from us? Do you want us to say "come on - live easy, explore and enjoy your freedom, PHP4 is a history - forget about it"? I understand that everybody hates support and would like to make constant progress, everybody wants to live in a better and brighter world, but world is as-is and there are A LOT of PHP4 packages what depend on PEAR. Experiments and quality are somewhat contradictive. Either you stick with quality and support or experiment with new PHP5 features to gain negative feedback which will be silently skipped. This law works independently of one's promises and opinions. b. Come on - drop the support and make it one more PITA for providers and customers as it already was with PHP5. Programmers can live with it, but if you want PEAR to mean something, try to understand - there are a lot of PEAR users (read - devs) WITHOUT PEAR accounts, who doesn't have a right to vote, who doesn't read this ML and some even do not know where PEAR code in their product or site packages comes from. Everything they have at hand are bugtracker and a big PEAR bible to pray we (developers) will be kind enough to save them from troubles. c. Since PEAR is world-exposed - ask the world loud and clear - not me and not here. d. But if you'll ask me - I answer that before making such changes consider upgrading your support services. Can you write a report about how wide PEAR is used? What happened over the past few months? A report about problems PEAR users face most often or how often do they face these? What is the effect of QA team created and results of their work? e. Consider writing template for proposals to stop others from wasting time asking questions what should be answered beforehand. Yes, PEPR is an artpiece of code, but it rather useless in action and there are many problems with using it you do not have any means to figure out why or do not want, because strictly speaking these are not about programming. f. PEAR should be more predictable and public exposed. That means more project planning work to increase visibility into PEAR future at least for a half year ahead. That means monthly or quaterly reports. More accessible PEAR for users, not only for developers with @php.net accounts. More respect to original authors to be included in package title page along with leads and maintainers. g. Another classical problem with package2.xml is consequence of bad engineering approach and I wonder if package.xml could be made extensible at first? The same is true for the rest of PEAR. With 1.4 version there are a lot of options, but more !== better. The list doesn't even fit my console screen - and many of them are obscure for users. You're introducing root level channels paradigm, but explain what is it this only in Chapter 21 of PEAR bible and it doesn't explain well why channels are good. There are the reasons mentioned: they good because - simpler, better, effective and robust they good because - old approach has "several bad side effects, the most obvious of which is that code size increases dramatically, and makes upgrading for a minor bug fix a complicated download for the user" But stop - PEAR is good, how come he had problems? What is this "complicated download" to invent channels? How do they "eliminate this and other barriers to application development"? The main question is still here. You need to separate desirable from real. Just curious how many bugs where found since the phrase "the PEAR installer has reached maturity as an enterprise-level installation tool for PHP code" hit the web? How many will be found and reported? How many will be found, but not reported? h. PEAR means "PHP Extension and Application Repository", but can you explain why packages are dependent on Repository class? Do you remember how it started - basic support for consistent error-reporting and destructors. It is no more actual for PHP5 and PEAR class is no more a necessity. What benefits come with PEAR dependency added to a code? Do you have a link to explain that to a totally dumb user like me, who doesn't have time to even read the replies and have no desire to wait for them either, who want the answers here and now or else he will loose the interest? 0x1 If you want a good engineering approach - think about separating PEAR as a repository and PEAR as a programming paradigm. On a lowest level it will be to move PEAR class functionality to specialized classes alike log4php or php4destructor instead of trying to grasp everything under PEAR logo. 0x2 Define some kind of template for plans. It should include problem introduction with links to bugreports/RFE, descriptions, mails. It must include all necessary info to make a decision. It must be document to ask questions. 0x3 Make a community, not just bunch of developers who has a free time to chat in this ML. Start with monthly newsletter which will show the true nature of PEAR to the world. [1] http://pear.php.net/news/ report on how PEAR gone dry [2] http://www.zend.com/zend/pear/ another abandoned log t --