Re: [pear-webmaster] Re: Help with installing PEAR

Anatoly Techtonik wrote:

Hello Greg,

Also notice, that offline install from 4.3.9 is not possible this way due to missing PHPUnit-0.6.x in distributive. Don't know about 4.3.10 version.

GB> ??? PHPunit is not required to install PEAR. Well, yes, it is not required, but I am unable to install DB, Net_Socket, Net_SMTP, Mail or XML_Parser from PHP distribution in offline mode like it might be described in PHP PEAR books or tutorials. "The following PEAR packages are bundled with PHP: DB, Net_Socket, Net_SMTP, Mail, XML_Parser, PHPUnit-0.6.2." I guess you know where this phrase comes from, but it is lie - PHPUnit-0.6.2 is not bundled with PHP anymore. It is sad to notice, that the problem was introduced in 4.3.9 and followed into 4.3.10 through some -RC releases.

I see - this is yet another coordination problem - are you talking about windows .zip files of php? These are created independently on another machine, I unfortunately have not much time to research this or do any other serious coding for a short while, as my quartet is preparing to record the Brahms Clarinet Quintet as well as playing several important concerts. Soon, I will have more time, maybe even a few minutes this weekend, we'll see.

Question above was already arised some time ago in this ML. There were even some patches, but I don't have any information about them being integrated. See: Re[2]: [PEAR-DEV] Re: go-pear. Was:Re[2]: [PEAR-DEV] XML_RPC start http://marc.theaimsgroup.com/?l=pear-dev&m=110243086805761&w=2 some follow-ups (can't find message from Lukas Smith though, it is dated 80 minutes later after my post) http://marc.theaimsgroup.com/?t=110243298400004&r=1&w=2 http://marc.theaimsgroup.com/?t=110252731500002&r=1&w=2 Support here is very different and sometimes too often it is trying to convince "you don't need that" in opposite to following guidelines of commercial support "client always right". It is a pity to receive an answer

Commercial support is "the client must be placated by people with no programming experience and lists of soothing phrases that always lead to the suggestion to re-install windows"

"me works for free - i don't have no time nor desire to do that" or even worse "i won't apply it and I hope others on the team won't either" though patch was already done and tested. In couple with strict rules about PEAR developers must be lead for useful packages it is almost impossible to make something good for PEAR when everybody else are too busy. Either quality or community - IMHO PEAR need to define priorities.

OK, I will only say this next part once, I promise. It's possible to have both. Rather than throw up roadblocks and complain, provide proof that you are in favor of both community and quality. All I have seen from you is that you are in favor of someone else doing the work for problems that you seem to be an expert on. If you're an expert on a problem, then fix it and provide a patch. Communicate with people who have cvs commit access, and *CALMLY* explain why the patch works. In addition, *LISTEN* to the responses. Don't write off your fellow developers as evil or callous because we bristle when you procede to say our code is flawed and our work ethic is worse. When you join the open source community, it is a proud moment. You are now saying "I am not a dribbling little baby who needs a 'the-client-must-be-placated-by-people-with-no-programming-experience-and-lists-of-soothing-phrases-that-always-lead-to-the-suggestion-to-re-install-windows' person to tell me that I am OK and the program will be fixed for the low price of $99.95 to upgrade. NO! I have the programming skills and the people skills to provide a working patch, and to fix it when others see problems with my imperfect fix for their imperfect programs!" That's the whole point - this is NOT your father's crap-ass support. No, you have the full power to take an hour or two away from the normal workings to find a fix and apply it. In addition, you DON'T have to take 15 hours away to code around something that will never be fixed unless you shell out more cash. As an example: Last year, I was pushing for a patch to the PEAR installer that would enable a new command called "revert." This would have provided the option to quickly restore an older package version that works, replacing the existing non-functional newer version. There was a lot of opposition, and I kept modifying, and modifying the patch. Finally, it became obvious that it would never be accepted, even though it was tested, fully working, and pretty neat. Instead, I changed my tactics, and realized that the problem was in fact that people could release packages that break backwards compatibility with impunity. So, I began the conversation to set the much-hated and much-loved BC standards. What we came to is very different from my original idea, because I modified it based on what people said, yes, even some curmudgeonly comments that annoyed me. The fact is, when people make curmudgeonly comments, it's not always because they are curmudgeonly. Sometimes it's because you say incredibly stupid things because you are human, and by you, I mean I, you, him, her all of us. I've since erased the fully working, beautifully wrought-out "pear revert" patch because it was unnecessary, and did not solve anything that community work could not do better. How could I have known this at the time if the existing community did not insist that I was wrong? On the other hand, the patches I provided for --alldeps and --onlyreqdeps were very well thought-out, and sailed through with no opposition whatsoever, because everyone agreed they were important and useful. Don't blame the developer if your suggestions are half-baked. Bake them more fully and you will find yourself an accepted member of the grown-ups club that is open source. Greg