Comments on: How would you improve PEAR?

By: udo

udo — Tue, 17 Jul 2007 11:28:32 +0000

Asking developers who cannot devote much time to step back and let others do the work.
It is no use for nobody when the estimated time of getting a usable package is many years in the future. If somebody does not have the time, he shouldn’t attempt to create new demanding packages.
There have to be regulations of how long a package can stay in alpha and beta state, before the project lead is vacant.

By: Evert

Evert — Tue, 19 Jun 2007 18:09:17 +0000

I think one very positive change would be less bureaucracy..

By: Stuardo -StR- Rodriguez

Stuardo -StR- Rodriguez — Thu, 31 May 2007 21:51:55 +0000

* read the patch ppl send. We have found many bugs, send the patch, never see the updated, and read that someone else has, found many bugs, send the patch and never see the update.

* pear upgrade-all –alldeps

* pear install package –target ftp://user@server.com/path

* E_STRICT pls, force all packages to be upgraded for PHP5

* let other projects be hosted by the pear channel in their own namespace, like
pear install Solar_SolarFramework
pear install Zend_Framework

By: DC

DC — Wed, 09 May 2007 04:34:38 +0000

Improve by Keeping up the good work !!
DC

By: Joshua Eichorn's Blog » Blog Archive » Thanks for your thoughts on improving PEAR

Tue, 08 May 2007 16:43:55 +0000

[...] The weblog of Joshua Eichorn, AJAX, PHP and Open Source « How would you improve PEAR? [...]

By: developercast.com » Greg Beaver’s Blog: Is anything working in PEAR?

developercast.com » Greg Beaver’s Blog: Is anything working in PEAR? — Mon, 07 May 2007 21:53:47 +0000

[...] going on with the PEAR project. Newly elected PEAR Group member Josh Eichorn posted a blog entry, “How would you improve PEAR” recently. I was impressed with the response, it seems many people outside of PEAR are monitoring it [...]

By: TomekG

TomekG — Sun, 06 May 2007 17:27:42 +0000

a better looking website! look of all php sites (php.net, pear.php.net and so on) is kinda embarracing in comparision with e.g. http://www.djangoproject.com or even http://www.rubyonrails.org
I could even contribute something myself in that matter

By: Bertrand Manson

Bertrand Manson — Sun, 06 May 2007 08:00:30 +0000

I’d like to see PEAR_Exception as an independant package.

By: Stan

Stan — Sun, 06 May 2007 00:27:38 +0000

Greg,
Excellent! I didn’t see your name anywhere on the list and was concerned that PEAR was missing out on a valuable resource - I only keep up to date on PEAR-appenings from time to time.

Thank you for pointing out the implementation of some of these suggestions - I think the general feel of some of the posters here is that these are great moves… we all just hope they are contagious to other parts of the project. I’m hopeful for the direction PEAR is headed in.

On a slightly side note, noticing the release of HTML_AJAX 0.5.1 today - and thinking to myself that a bridge between HTML_AJAX, it’s internal JS library and jQuery or even Prototype would be handy. I’d love to see PEAR in general adopt some bridge-type packages for interacting with already establishing open source libraries. HTML_AJAX in particular has the potential to be driver-based and allow PHP developers to keep up with their existent JS practices. How cool would that be?

Anyhow, that’s my $0.02 - but don’t take it to the bank.

Pax,
- Stan

By: Gregory Beaver

Gregory Beaver — Sat, 05 May 2007 00:58:09 +0000

For those who are wondering, most of the suggestions here are in fact already implemented or in the planning stages. There is really only one that is not:

1) SVN. CVS is here to stay, as we are dependent on cvs.php.net. HOWEVER, someone willing to donate dedicated hardware would pique our interest in having optional subversion hosting.

Things that are implemented already:

1) pear installer is capable of modifying php.ini, but it does require a binary package to be created with the dll.
2) PEAR_Exception is the error/exception base class.
3) Mentoring. The new constitution (http://pear.php.net/manual/en/constitution.php) requires mentoring of new developers.
4) package tags. This was recently implemented, in anticipation of the new collectives, and other useful purposes.
5) deprecated/unmaintained packages have been supported for a while now (see http://pear.php.net/DB for an example)
6) lightweight packages. See http://pear.php.net/MDB2 for an example. All of the database drivers are decoupled into subpackages. Structures_DataGrid is the most complex example of this de-coupling. The technical capability was not present before PEAR version 1.4.9 to handle this properly, and so most packages have not yet implemented this functionality.

The social issues are a real problem. I plan to make this my primary purpose as the PEAR president (this is why I’m not in the PEAR Group Stan, I ran for the president of the whole thingy), separate from my work as a developer. We’ll see how it goes, but I see a strong momentum shift in the makings here, which has been my dream for several years. It’s exciting to see it moving forward so dramatically. I hope that more developers who see the potential and the things that can happen will join, it is only through the force of the will of people who believe in things like civility that PEAR will shift its culture to one that encourages innovation as well as stability.

One thing you can currently depend upon in PEAR that will never be changing is that packages marked stable will always work in a similar way, such that you won’t find applications based on them suddenly breaking on upgrade. Innovation can always be provided without destroying the work of your users. Stay tuned for details of how things will be changing