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

Scott Mattocks wrote: > Ian Warner wrote: >> I think there is a lot of validity in getting nitpicked by the >> developers and the users also, probably the user more than developers >> in all honesty! Most users I assume don't install packages that are >> not in the package list, if they could install ALPHA / BETA packages >> of all proposals then there is a wider community to give the feedback >> - this will make the packages better surely, and give some motivation >> to the developers and steer the package the right way. So I think that >> allowing all package proposals as long as they meet Alpha standards >> should be on the list for PEAR install - then to meet stable >> requirements takes a whole lot more. >> > > I don't think that adding a bunch of proposal packages to the PEAR > channel will do much good. It will probably just add a long list of > confusing and not up to par packages. What might be helpful would be to > create a proposal channel that could house all of the proposal packages. > This would keep everything separated so that full PEAR packages are easy > to find and proposals are easy to install. Hi, Although a great idea, this is also not technically feasible right now. Among other considerations, the database for PEAR is several GB in size, and we share the box with pecl (for now), integrating another channel into the machine could bring us back to the old days of restarting httpd every day once or twice. The truth is that proposals can easily be installed directly now: pear install http://example.com/path/to/Proposal-0.1.0.tgz Also, migrating a proposal package to the PEAR channel is non-trivial, so this needs to be considered carefully. If we plan to open up PEAR in the proposed way, it will essentially be time to ask a large company to sponsor PEAR and provide full-time staff to maintain the website and provide lots of hardware. I'm not sure we're quite there yet. As it currently stands, there is a lot of database design tweaking before pearweb will be able to handle its current load well enough even to display statistics. Yesterday I enabled the stats on my local copy of pearweb, and even with my monster machine it took 20 seconds(!) to run the query that is in package-stats-graph.php. Several people on irc are trying to help me optimize this query and re-factor the design to be efficient at all. I spent all day yesterday on the dang thing without coming up with a good solution. Even refactoring the table will be tricky. I wrote a simple script to iterate over the downloads table and scrunch it into another much faster format, and by my calculations it would have taken 18 hours to complete. Obviously, running a thing like that on the live server is not an option. This point is that even with our existing hardware, it won't be enough power to support an influx of hundreds of proposed packages unless we complete the work on pearweb optimization. As always, technology innovation must precede political innovation (real world example: industrial revolution made labor unions possible, anti-trust laws necessary, etc.) Greg