practical concerns for moving PEAR forward

Hi all, As a follow-up to my previous message on abstract ideas, I would like to point out some practical concerns from my experience working on both PEAR and phpDocumentor. First off, doing a complete rewrite of pearweb from scratch throwing everything out and starting over is impractical, and will simply lead to nothing getting done. PEAR has 409 packages at the moment, and this is no accident: more than 1 thing in PEAR really works well. Sure, we have some problems that need fixing, but let's avoid introducing new ones. Those who want to help redesign the PEAR project need to understand a few things: PEAR is pear.php.net. pear.php.net gets approximately 800,000 hits/day, and our mysql database is HUGE. Any minor change can severely affect performance, and even bring down the whole site (API docs generation, for instance). pearweb was designed when PHP 4 was new, and takes advantage of several weird PHP tricks, such as a auto-prepend and an auto-append file, and it also relies upon mod_rewrite in apache. In addition, all downloads pass through a PHP file named "get" which masquerades as a directory. pearweb has a huge number of dependencies, all on PHP 4-based packages. In addition, it was designed monolithically, so internally everything depends on everything else. Making a change in one place can have an unexpected effect on random places in the website. All of the ideas on changing political structures of package categories or groups will have a significant impact on the infrastructure of the website itself. Before we can make *any* changes to pearweb (and hence, any political changes), we will need to refactor the site to be much more efficient and streamlined. Rather than make a huge rewrite, I would like to see a few big changes done incrementally. First is making it possible for people to install the thing locally quite easily, and hence this means making it PEAR-installable. Next is de-coupling code so that changes in one location don't affect others, and simplifying the code structure so that it is even possible to make changes. Finally, it will be ready to make changes. None of this work is sexy, but the result will be. Believe me, I'm all for a frank discussion of PEAR's political structure, but I would like the result to be implementable in this century, if possible, at pear.php.net :) Greg