Re: PEAR a way forward
| From: | Jeff Moore | Date: | Thu, 05 Oct 2006 17:58:08 +0000 |
| Subject: | Re: PEAR a way forward | ||
| References: | 1 2 3 4 5 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-44376@lists.php.net to get a copy of this message | ||
On Oct 5, 2006, at 12:34 AM, Greg Beaver wrote:
Taking a step back, let's look at these "good" ideas: which ones succeeded? The answer is quite clear. Ideas that start as ideas have at best limited success, and at worst a terrible track record of offending and scaring off developers. Ideas that instead start as technical solutions and implementations eliminate the need for ANY political discourse, and make our lives better.Hi Greg, A very Interesting analysis. I'm an outsider, but I thought I'd comment anyway. What I get from this analysis is that PEAR needs some sort of incubator where technical solutions and implementations can grow up outside of the political process. One of the things I thought that channels were supposed to do is to help some opposing views co-exist, by providing multiple official PEAR channels. Why hasn't this happened? Perhaps SVN support and branching support in the various tools would help support this? I also notice another divide, between tools and infrastructure and libraries. Infrastructure being things like PEPr, the installer, phpDocumentor, etc. These are uncontroversial and successful. On the other hand the libraries, things that are meant to be included directly into end users programs, are much more controversial. PEAR seems to be looking for some goals. I would submit that on the library side, a generally agreeable set of goals is going to be hard to reach and contentious. However, on the infrastructure side, developers are more concerned about the features the tools provide than on the code that provides it. It should be much easier to establish goals for the tools. Perhaps a split would be helpful? The PEAR project could choose a more limited scope of providing a PHP based open source project management infrastructure. This would have a clear set of goals. This project could also take a more customer oriented and outward focused perspective of providing project infrastructure for the PHP community as a whole, rather than primarily focusing on the PEAR project. This project would be more product and feature oriented. While PEAR-FORGE would incubate high quality, peer reviewed packages. I'm not suggesting opening up hosting to anyone or anything, just allowing multiple points of view within PEAR, each centered around a channel. Again, I'm an outsider, so there is probably much that I don't understand. These are just some thoughts for your consideration. Regards, Jeff