Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Daniel O'Connor <daniel.oconnor <at> gmail.com>
Subject: Re: Moving to a new PEAR website
Newsgroups: gmane.comp.php.pear.devel
Date: Sunday 1st May 2011 08:58:40 UTC (over 6 years ago)
>
>
> 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.
 
CD: 3ms