Re: wiki page for HTTP_Request2 inside

Alexey Borzov wrote: > Hi, > > Gregory Beaver wrote: >>>>> The package may not have HTTP_Request as a required dependency since >>>>> HTTP_Request is not a E_STRICT compatible package, see >>>>> >>>>> http://pear.php.net/pepr/pepr-proposal-show.php?id=419 >>>> There is no E_STRICT alternative to HTTP_Request, I strongly recommend >>>> we allow dependencies on older packages when there is no alternative. >>> I strongly recommend going the other way round and "fix" the package >>> in question instead of fixing the rules each time. One of the goals of >>> my E_STRICT RFC was to encourage the rewrite of base packages like >>> HTTP_Request to PHP5 (yes, I know that I'm its maintainer, but outside >>> help won't do any harm). >> >> Everyone is in favor of newer packages to implement better fixes for the >> problems solved by the old packages. Should we then simply reject new >> packages like Services_Digg if they do depend on existing non-E_STRICT >> packages? I fear that this is a good way to deter developers from >> joining PEAR (not in Joe's case, he's been around, but others who lurk >> on the list will see this). > > As I already stated, one of the goals of my RFC (which passed with +16 > half a year ago, so I am a bit curious why there are so many people > acting surprised *now*) was to encourage the rewrite of "base" packages. > > I'd also like to remind that there was a list of "base" packages posted: > http://marc.info/?l=pear-dev&m=115264520301256&w=2 > and HTTP_Request had a prominent position in the top priority list > *back then*. This list is an email message, but can't be found anywhere on the pear.php.net website and clearly demonstrates the importance of *not* relying upon emails to document important details. You know this email because you sent it :). I have never seen this email because I didn't have good internet access for pretty much all of July last summer. > So the real question we should be answering is not "how do we weasel > Services_Digg into PEAR?" but "how do we encourage rewrite of 'base' > packages at last?". Weasel? Please, Alexey, try to be civil. > >> Since the E_STRICT RFC was accepted, how many packages have in fact been >> rewritten to support E_STRICT? On my quick scan of the packages list, >> here are 5 packages out of about 350 or so PHP4-based packages. We have >> on the other hand, had many new submissions of PHP5-based packages. > > ...thus we should change our rules so that it won't even be necessary > to rewrite PHP4 packages. Nice. :) Let me quote myself from this very message: "Everyone is in favor of newer packages to implement better fixes for the problems solved by the old packages." Perhaps this sentence is unclear. Let me try again. Everyone wants old PHP4-based packages to be refactored to take advantage of new features in PHP 5. The current rules are not encouraging ANY change. Your original list of packages from last summer is unchanged, no new conversions have happened in spite of the RFC. If the RFC is intended to encourage conversion of old packages, empirical evidence says it is not working at all. In no way does this mean it won't be necessary to rewrite PHP4 packages, but if the choice is between bringing an interesting new package to PEAR - and rewriting 4 dependencies - or taking it to Zend Framework and rewriting none of them, what would the average user do? > >> I am pretty sure that if we *really* want to encourage people to >> re-develop existing solutions in PHP 5, there needs to be more carrot >> than stick. In other words, rather than punishing people who submit >> packages that are written in PHP 5 but depend upon older solutions, we >> need to create a good reason for developers to devote time to fixing up >> an old solution into the new language features. > > Here I agree. Now, what would you suggest as a carrot? The section of my original message you cut contained my suggestions. Here they are again: "The other day, someone on IRC mentioned that they would like to see package requests for PEAR. I would like to refine this idea a bit, and have per-collective roadmaps, where users can request a solution to a problem, which can then be assigned to the roadmap for a collective. This would allow those of us inside PEAR to request, for instance, a PHP5-based implementation of Net_Socket, and visibly assign it to a collective's roadmap. Then, if we rework the front page of pear.php.net and provide a "Want to help out?" link, I suspect we will find the conversion rate of existing packages will climb significantly." Basically, the carrot I'm suggesting is based on the assumption that people want to be a part of a clear and exciting mission. Currently PEAR's mission seems to be "submit new packages and try not to screw up too bad." It may say something different in the documentation, but look at the evidence: PEPr allows submitting proposals only for RFCs and new packages. All attention in recent history (with the exception of HTML_QuickForm2 and to a limited extent PEAR2) has been on new packages. Any mention of refactoring old packages is limited to occasional email messages. Obscure references to passed RFCs that are hard to find in the documentation don't count imho. To be explicit: the carrot is that open source developers take pride in doing something original with a problem that needs to be solved. First, we need to convince developers that this problem is important to them and to PEAR and that PEAR is important enough to need time committed to help solve it. Simply forbidding new submissions that rely on old packages because there is no alternative is not going to work. Joe, for instance, said he'll just use file_get_contents() for now and wait for the maintainers of HTTP_Request to get things done. All I'm asking is that we be realistic: we both want the quality of PEAR to increase, but my priority is to get things fixed by getting more developers involved. We do not have enough people yet to maintain the existing packages AND re-develop all of the old ones, although I think numbers have improved in recent months. I know you're frustrated, having waited this long for so little to happen. I hope you'll trust that I, and many others active on the list, really do feel the time is right for some great changes to get stuff happening for real. No one wants to take a giant step backwards and suddenly allow new code to be non-E_STRICT. It's only a question of how best to encourage the old stuff to become E_STRICT. Thanks, Greg