Lorenzo Alberton

London, UK   ·   Contact me   ·  

« Articles

Get involved in PEAR!

PHP, PEAR   ·   15 November 2006 12:08

Abstract: An overview of the many ways to get involved in PEAR, and a few concrete suggestions.

I often read on the mailing-list or in some forums that PEAR is nothing more than a repository of mixed-quality PHP packages, and is ruled by a bunch of temperamental people. As such, people reading such comments think that a) the whole PEAR project is not even worth a look, or b) getting involved in PEAR is impossible if the core PEAR guys are not in the mood of approving the package you just submitted.
While I *have* seen some heated debates between some core developers and "outsiders" in the past, that resulted in having the new package rejected and the newcomer pissed-off, that is certainly not as frequent as you may think (ever heard the adagio «A falling tree makes more noise than a growing forest»?), and in the few cases that happened it was because of a wrong attitude.
To avoid it, you just need to be polite, open to suggestions, and accept the rules of the community you're trying to enter. If your package is original, generally good and fits PEAR, then by all means, submit it and wait for suggestions and votes! I'm sure you'll find a lot of nice people in PEAR to work with!

Do you think you can do better?

We're all happy to hear new ideas, or to improve something we already have. There are many ways to contribute, and while proposing a new package could be the most "rewarding" for the creator's ego in the short term, it's certainly not the only one.
Quoting the PEAR manual: "PEAR is an open source project, which means that everyone can help improving it. Improving doesn't always mean writing code. It can also mean reporting bugs, giving feedback, submitting feature requests and even financial support".
By the way: I didn't see "grunting and bitching" in this list ;-)

Bugs and patches

One of the most useful contributions you can make is reporting bugs when you find one, or help in fixing them.
If you want to have a bug fixed, maybe you could send the package developer some incentives to make it happen faster ;-)
If you have some spare time and really want to get involved, open this page and see if you can help fixing existing bugs. You don't need a CVS account to post a patch. Eventually, if you show your dedication, you can be "promoted" to active developer, if you want so and if the package lead values your help.
If the original developer isn't active anymore, you can take over the unmaintained package.

Documentation

If you think that the documentation for a PEAR package is incomplete, informing the developer about the undocumented area(s) may be a sensitive action. Better yet, if you are confident with the package, and can provide some examples, tutorials, guides or give a hand in writing the docs, contact the pear-doc mailing-list, or read here about the peardoc DocBook format.

Feedback

Often, when we introduce a new feature in an existing package or are working towards a nice API, we may ask for feedback, to collect some ideas, suggestions, or hear some use-cases. Unfortunately, we don't always receive many comments. If you have experience on the topic, then speak up!

OK, where should I start?

If you paid attention, I already pointed a lot of ways to "get started". If you lack ideas and/or still need some concrete suggestions, read on.

Mail_Queue2

The Mail_Queue package probably went "stable" too soon, but it still needs a lot of love. Since we can't change the API of a stable package, here's a list of improvement needed for the new Mail_Queue2 (for whoever feels brave enough to write it):

  • support for multiple recipients (Cc/Bcc) (this is somewhat solved in CVS already)
  • db (row-level?) locking to avoid concurrent access and multiple deliveries
  • proper logs and error handling (mostly non-blocking, since we're sending emails in batches)
  • support for priority levels
  • accept an already instantiated db container
  • support for persistent SMTP connections
  • better queue/buffer management
  • new containers (PDO)
  • ...

[M]DB_QueryTool

Another popular package that needs some help is MDB_QueryTool. The most urgent thing to do is implement identifier quoting (i.e. quote table names). There is more than one request about it already.
Then it would probably benefit from a full source code review, it's been ages since the last spring-cleaning session ;-)
It would also be cool if someone could backport to DB_QueryTool the last changes applied to MDB_QueryTool.

MDB2 and charsets

I've already asked for feedback in a previous article, and received zero comments, but the issue is still open, and its solution is critical for other packages as well, Translation2 in primis.

Translation2

Translation2 is supposed to make the developers' life easier when building a multilingual application/website. It has been through a looong beta-cycle, and still hasn't reached the "stable" status, since I'd like to receive some more feedback about it.
I'm particularly interested in suggestions on how to handle charsets and encoding with the db drivers, how to deal with "default" translations (i.e. default replacement for untranslated strings), about its cache decorator, about new containers (php array, ini files, ...), etc.

Translation2_Converter

An idea for a new package (or group of packages): a converter to move data among the existing Translation2 storage containers, e.g. database to XML, gettext to database, array to database, etc. I'd love to see a core module (maybe with an intermediate storage format), and a series of drivers (one for each Translation2 container) to convert to and from the format used in the core module.

Are you still reading?

What are you waiting for? Roll up your sleeves and get your hands dirty! Get involved now!

Back

Latest articles

Filter articles by topic

AJAX, Apache, Book Review, Charset, Cheat Sheet, Data structures, Database, Firebird SQL, Hadoop, Imagick, INFORMATION_SCHEMA, JavaScript, Kafka, Linux, Message Queues, mod_rewrite, Monitoring, MySQL, NoSQL, Oracle, PDO, PEAR, Performance, PHP, PostgreSQL, Profiling, Scalability, Security, SPL, SQL Server, SQLite, Testing, Tutorial, TYPO3, Windows, Zend Framework

Back