Re: PEAR a way forward

Craig Constantine wrote: > In the immediate future, the web gang is working on immediate, pressing > issues. These issues are urgent (and therefore very worthy of the excellent > work being applied), but pearweb itself is not important compared to the > overarching issues PEAR faces. Hi Craig, Having been here for a while, and been active in both dreaming up ideas and implementing them, I have seen a distinct pattern in the way things work in PEAR. Here's a few important changes that have happened while I've been here: 1) no breaking BC once a release hits stable, new package for major version increase 2) PEAR channels 3) PEPr (this was not my idea or my code) 4) version numbering scheme Let's take a close look at what has been successful: 1) no breaking BC once a release hits stable, new package for major version increase This idea is a political change to PEAR that affects the way we technically implement our classes. Although controversial, it has finally been grudgingly accepted, but is still not documented clearly. Some developers have left PEAR in part because of its implementation. 2) PEAR channels This idea has been uncontroversial from its beginning, but has expanded the political dialogue tremendously, resulting in the attraction of several new developers to PEAR that would not otherwise have discovered it. PEAR Channels were introduced as a new feature of the PEAR Installer 1.4.0 3) PEPr This has revolutionized PEAR. Before PEPr, packages were voted in through emails on pear-dev where developers would send a +1 or -1. It was haphazard and difficult to tally totals. Any debate resulted in tremendous FUD and wasted bandwidth, cluttering important technical discussions on pear-dev. Toby Schlitt wrote PEPr - and without asking permission. He simply debuted it and said "Here is PEPr, which does what we do now, but better." Initially, there were lots of kinks to work out, and he adjusted it based on voluminous feedback. Once PEPr started being used, it literally ended all the political bickering over package acceptance, with the exception of one really volatile package (XML_RPC2), but this eventually resolved in a new vote 6 months later and acceptance of a great new PHP5-based package - a resounding success. 4) version numbering scheme This idea has been *extremely* controversial from the beginning, unclear, and documentation is scattered amongst several RFCs, PEAR Group documents, and is definitely responsible for being the last straw of one developer leaving PEAR. Confusion STILL abounds as to what it is, what it means. 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. Rather than talk about over-arching issues, let's take things a step further - how can we solve them using the tools we have? For instance, the version numbering snafu can be solved with a simple form on pear.php.net, and using PEAR_PackageFileManager. Imagine a page where you can check a few options: next release is * stable * beta * alpha * devel get a suggested version number back Version 1.2.3 OK? [OK] click OK, and it provides a cut-and-pasteable package.xml based on previous releases, or if there are none, based upon the package information. This would solve the version numbering questions because you would just follow the convention from the web site - no need to think, and no arguing. There would be no point, because the answer would be "but pear.php.net told me to use version 1.2.3" People are talking about doing innovative things with PEAR, but if we have to walk on eggshells just to make a tiny change to pear.php.net, this is simply not possible, because we lose the benefit of multiple developers through CVS. The fact is, a REAL political solution will come from a REAL technical solution. This means: 1) better hardware for pear.php.net 2) easier development of the code running pear.php.net 3) better collaboration tools at pear.php.net Only once these three needs are satisfied does it even make sense to talk about anything else. Creating spaces for innovation at pear.php.net will very quickly reflect this on pear-dev, in the attitudes of developers and the packages we write. When I asked to lead PEAR forward last week, this is what I am talking about. EVERYONE's ideas I've read here are well-considered, worthy of serious consideration, and important to implement in some manner. I believe strongly that we first need fantastic tools, and then we need a fantastic mission to direct the usage of these tools. We're not like an ordinary business - the tools we need don't require any investment (no sunk cost) and are easy to set up by simply downloading and installing them. As for the top 3 priorities above: #1 is on its way to being fixed, Martin will be able to write a message with details once the change is finalized - we are making serious progress on this front. #2 is on its way, as I've made the installer pear-installable. Once we switch to the new hardware, I'll work with Martin to instead make pearweb installed from a PEAR package. There are a couple of ways of doing this, we need to work out how. This will free up CVS of pearweb to be used for REAL innovation. #3 is also on its way, as we are looking at enterprise-level bug and collaboration tools, including wiki or wiki-like tools to make this possible. Once we have a real collaboration in place, it will be possible to have PEPr-like voting on features, real roadmaps for the PEAR project as well as packages, clear delineation of priorities, and everything we need to organize our future. In short, if you have an idea, think first about how you could implement it with a technical solution that would make the idea second-nature, this will simply guarantee its success over an RFC or a PEAR group document. Thanks, Greg