Re: Moving to a new PEAR website

On Sun, 2011-05-01 at 18:28 +0930, Daniel O'Connor wrote: > > 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. > May be we should put Google Analytics on the current site so we can see how people are actually using it. I think there is probably a small set of inbound link types that could be handled via rewrite rules. > 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. > Indeed, but I think it's a risk we should consider. The technical requirements for the PEAR2Web site are considerably lower than pearweb. The readme file distributed with the git repo allowed me to get up and running in about 30 minutes, and I don't have much ops experience. > 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? > I'm not sure what the alternative is. A slower migration might work better, but we need to have a plan of some sort. > Packages which are clearly dead get "put down" in another channel? > I'm in favour of us officially abandoning certain packages. We really can't promise quality for things that were contributed years ago and have not been updated since then. Other projects like ZF are doing the same thing. Community contributed packages from ZF1 that are not maintained and have no more active developers will not be available in ZF2. > 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); > I'm not sure why more people have not moved packages over. Part of the problem is it requires a time investment many don't have, and requires breaking BC with existing stable packages (namespace support). For me, I'm just now starting to consider moving my maintained packages to pear2. > or we're simply crushed by the fact the pear installer is bundled with > plenty of distributions, pyrus is not (to my knowledge) > Part of the awesomeness of pyrus is it doesn't need to be installed, or to be bundled by default. It works as a stand-alone tool and favours a per-project pear repository over a global system-wide pear repository. I think its lack of adoption is purely lack of exposure and documentation. Most don't know it exists, those that do know it exists don't know why it's better or how to use it. > 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'm open to this approach if others are interested. It certainly reduces the focus and amount of work required. > 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. > Agreed, but who will be the project manager? I have goals I've outlined in my original message but response has been tepid. I'm available to do design/implementation for the new site, but don't have a lot of time besides that. Cheers, Mike