Re: PEAR's mission statement - let the fun begin

On 10/15/06, Alan Langford <jal@ambitonline.com> wrote:

On 2006 10 15 04:35, Ian Warner wrote: Christian Weiske wrote:

Daniel and Ian,

To get code into PEAR, it has to run a gauntlet of picky, fussy developers who will be against a package going into pear for very minor

deviations

from coding style.

I have never seen a package being refused because of coding standards problems. I have seen developers dropping the package because they didn't feel like complying to the CS and they were upset that someone tells them it's not clean, but the packages were not refused or rejected, but let alone.

PEAR should be more 'open', and relax standards in terms of getting

packages in

What I like at PEAR is that there actually are coding standards, and

the

(even if light) enforcement to document your code. I really appreciate that code in PEAR isn't some hackety-hacked-files that are unmaintainable, but you really have a base you can work with.

I actually think that our sometimes annoying conding standards is one of the reason that made pear pear and not phpclasses (no offense here - just stating an example). In order to stay a quality repository, we have to be strict and refuse *some* packages. But I must agree that yes, some other packages might be good in pear but not everyone is ready to comply with our rules, thus enough reason for me (imho) to refuse a package. I have seen some people being mad and deleting their proposals when we told them that it wasn't compliant and they argued that it was a good package anyway. Sometimes they were good packages, but if you don't follow the rules, you can't get in anyway.. and that's what makes pear better I think.. When people don't listen that's when the authority comes in, and at pear we need authority and rules in order to keep it good. Although, I accept the fact that if a package follows all the rules and the developer says he's going to implement more features later, then we shouldn't wait for that.

I think PEAR should concentrate on some niche packages also - i.e. Web Services is a good example. So instead of waiting for proposals a list of all the possible Web services should be gathered and then a call for developers to code these.

That's the wrong approach in my eyes. I develop and put code into PEAR because I actually need it, and not because someone out there needs it and not me. That is what paid work is for.

I am sure though that there are hundreds of developers around the world doing a Google / Amazon web service or something. Having something in PEAR to say Hey code it here, and some pointers /comments / discussion on what direction to take may mean that these developers come to PEAR and code it within these confines, the benefits are a community of 'experts' who can help and critique, plus a community of users who will bug fix with you. If no one wants to code the package then fine it stays listed as unmaintained - people can still though comment (hopefully this feature will be added) on these. But what I am trying to do from my suggestion is get people interested in developing with PEAR to say that a package is already passed the proposal stage cause we feel we need it. Ian has nailed this one exactly: I'm sitting here with an XML-RPC library that has evolved from a very basic library I found a few years back into one that has more and different capabilities from XML_RPC2. If I had known XML_RPC2 was "in the pipe" I could have spent my effort on it instead, and we all would have had a more capable package (RPC2 has stuff that's not in my library as well). As Christian points out, I built my code because I needed it. But I could have done it faster, more reliably, and given some of my effort back to the community if one of my many searches on the subject had led me to PEAR. Instead I get the much more difficult task of trying to figure out if I can find a way to merge my features into RPC2 and find a way to wrap it in a way that makes it compatible with my API. Yuck.

I think the point of Daniels email and what I read into it was that to get a proposal through was EASY - to get the proposal passed as STABLE is going to be tough, ie this is when CS and practices come under scrutiny, users of PEAR should be warned maybe that if the package is not stable then it may not live up to there expectations, but this goes without saying in most cases as the package would state Beta or Alpha. I like this idea a lot, as it will provide a means for collaboration at the early stages. I am taking it one further and saying let PEAR propose the package and get collaboration within the PEAR developers working at stage alpha, and get the base that you mentioned sorted. Some useful tips on how to write a mission statement can be found here - http://framework.zend.com/roadmap Send also have a package WANTS section, similar to what I am saying.

-- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

-- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18