Re: Moving to a new PEAR website

> > > At this stage, I'd love to hear feedback from the community about moving > the site. If the reaction is generally positive, the PEAR Group will vote on > moving things over. > > I like the idea; the motivations are right. I'm afraid of the implications of cutting over as you've described though. The immediate effects - broken links by the dozen; making it harder for users to report bugs, marking it harder for new users/developers learn how to interact with the community; confusing users as to the location of their old package (a common entrance path is typing "pear.php.net/packagename"; pepr/bugtracking problems; etc. Doing that while there's a declining amount of developers; including a declining amount of time existing maintainers can spend on infrastructure - it would be quite a risk. What are the alternatives? A phased migration? IE: the current pear installer grows support for 'package X has moved to channel Y'; and we take the popular, active packages over to PEAR2 (quickform2, http_request2, validate)? Co-branding on the current front page for 3-6 months? Packages which are clearly dead get "put down" in another channel? I think we've intended to take that approach since 2008 or before; but never really set a roadmap. Further; not many pear1 packages have made the leap across - there's something missing (tools; knowledge; or as you suggest; exposure); or we're simply crushed by the fact the pear installer is bundled with plenty of distributions, pyrus is not (to my knowledge) Another alternative is a change of focus. PEAR packages + the installer were the first major innovation; PEAR channels are *the* best thing that has happened since to allow other communities to provide their own libraries. Why not play to our strengths and split between a community for "installer+channels+best practices/reporting on new components and ideas" (think http://blog.stuartherbert.com/php/2011/04/09/gathering-requirements-for-a-pear-channel-aggregator/); close up shop doing individual component development - leave that for frameworks or other communities. It would be painful; but you'd see the ad-hoc communities around packages like Validate_* split off to do their own thing. We already know that can work by looking at how PHPUnit split off from us - nothing but a good thing in the long run. I think whatever we end up doing; let's actually put it in writing ( wiki.php.net - goal + steps); put someone in charge as a project manager; set a timeline; and start shipping.