RE: [PEAR-DEV] Re: [PEAR] Re: [PEAR-DEV] new template engine

Thomas, > IMHO the idea of PEAR is quite clear: "a set of highly reusable > components that meet certain requirements of coding standars, > documentation style, error reporting and quality". If Pear starts to > accept everything, Pear will become something like hotscripts and > believe me this will kill Pear. I never implied the idea would be to "accept everything." Standards would obviously be applied to the process to make sure quality was maintained. What I suggested was that those components that meet PEAR'S standards, should be considered and allowed in if they do (or at least considered on a case per case basis). The worst thing that would happen is someone has more choices when they use PEAR... something many would appreciate and I think would not hurt PEAR, and especially would not Kill PEAR. I surely do not see how doing so goes against the definition / mission you give of "a set of highly reusable components that meet certain requirements of coding standars, documentation style, error reporting and quality". If doing so would go against that definition please explain why. > I think that there are thousands scripts > that meet in purpouse the Pear classes, but if people choose to use the > Pear ones it's because them meet their needs. Yes there are thousands of scripts out their that meet various needs, however what we all need I would argue is a Standardized set of components that do in fact meet our needs which are in one place. That is something we do not necesarily have in the PHP community, nor will have if we do not relax to a degree what we will let into PEAR. I know I could use "a set of highly reusable components that meet certain requirements of coding standars, documentation style, error reporting and quality" that met my needs. More choices within that repository would only help me fulfill more needs... as I think anyone would agree that there is never a defacto standard one size fits all approach to any programming task. > Having many classes that > provide _similar_ functionalities only will confuse people and make > things harder to do, things like maintain, support or document. I don't agree, and I am sure many others would disagree with you. What things would be harder to do? If you are referring to maintenence... the components would be maintained by that group that maintains them, or uses them most to keep them useful to them, as for support, again they would be supported in the documentation like all other components, and if they lacked good documentation, then they probably won't get used much... oh well. If they are truly useful components, someone will write the documentation for them. I for instance am more than willing to assist in this area, and I am sure many more will come to volunteer to document a good component if the author doesn't. Besides, if PEAR has not defined standards for documentation, they should, if they have, then it simply is not an issue, it is a prerequisite like coding standards and unless documented correctly would not be a part of PEAR. > You talk about forks. Forks in Open Source software is a natural thing > and benefit the developers as they can choose what they want/need. But > forks _inside Pear_ will be evil for both users and Pear developers. No one is promoting forks within PEAR, just a more open / democratic and less threatened approach. > If > someone ask me, "what provides Pear?" and I answer "Pear provides 3 > abstraction layers, 8 template systems, 3 documentation methods, ...", > he probably will think that Pear is at least silly (including me in > helping that mess to grow ;). I'm friend of improving, enhancing or even > replacing but not of duplicating. I don't think CPAN is silly, obviously those who created PEAR didn't think it was silly when they were "inspired" by CPAN and created PEAR in the first place, yet CPAN consists of a variety of components and that has worked pretty well I would argue, I would even further argue this is what made CPAN what it is today, it's flexibility in allowing it to be what it is, and its usefullness... if one CPAN compnent is not exactly what you need, chances are there is another one that is. I fail to see how that would be silly... could you please elaborate. As for the differnt documentation you suggest, that simply would not happen, no one is sugesting allowing components in PEAR that are not consistent with PEASR Standards, I would not want that either. > I'll be very glad to see more developers joining to the Pear effort, but > for me to join to a proyect means help them, not "hey you, I come here > with my things put them over you and please also help me in maintain > them and correct bugs". As long as something was up to standards, and perhaps "experimental" until that time the PEAR community felt it was up to standards before releasing it as part of PEAR, isn't group collaboration a good thing? Isn't making creative contributions to something like PEAR helping PEAR even if it might be a rough contribution? It seems to me, if someone submitted a component that provided something innovative and creative and yet only had a few bugs to work out, it seems crazy to turn such a thing away. Besides, you speak as if you would be the only one actually working on the code base in PEAR, if there were more contributions allowed in as part of the project, the intellectual capital would increase as well, who knows some of these newcomers might even help debug your code every now and then and improve upon the PEAR codebase in other areas as well. > Pear is entirely open to anybody that comes with > ideas on how to improve actual things or developing new ones, and sure > will open their doors to you. The suggestion I am making is one that I honestly feel would help improve the whole PEAR project, and I am sure many others would agree. > The people that don't know nothing about Pear could think that Pear > developers are snooty, egoist, etc. ok, but nothing more far from the > reality as Pear is an _Open Source_ proyect and is making many efforts > to give the community good code and resources for distributing and > installing them in a easy way. I want to make sure I am not misunderstood here, I am very excited about what is happening with PEAR, and the efforts of those like yourself who are working hard to make it a viable source of code. I read the lists and see the contributions and I know, however, because I have been following things closely, I know that your efforts and intentions are commendable and personally, appreciated. However, when I mentioned what I did about PEAR's image before, I was speaking to a general image of PEAR that I have seen from others who like you say that "don't know anything about PEAR." There is a bit of a public relations crisis in the community. > Perhaps some parts not yet very > "user-friendly" but this subject is changing step by step. And of course > if you want to see that happen more quickly you only need to join Pear > :) I am more than willing to contribute in any way I can. I joined this list at Stig's request after meeting him at ApacheCon 2000 and seeking to volunteer to help with the web site. For the most part I am a web developer and would like to contribute my efforts in helping to build the web site and with documentation and or anything else I can contribute. Any ideas... let me know.