PhpRiot
News Archive
PhpRiot Newsletter
Your Email Address:

More information

Contributing to ZendFramework

Note: This article was originally published at Planet PHP on 1 September 2010.
Planet PHP

... on contribution

Who hasn't ever started writing his own Framework/CMS? It is considered best practice for learning purposes, but going through all the security stuff can be stressful and boring at the same time. That's where most devs start to contribute to big Open Source-projects like Typo3 or the Zend Framework, because they are already experienced working with it and yet evolving another system on the market or even getting people to contribute seems like an unachievable task. Instead of wasting his time on yet another ACL implementation, the developer is taking part in making a software become even better, no matter if he delivers new features, reports / fixes bugs or works on documentation (another, yet an often underestimated part of contribution). It is also worth noting that every single Blog-entry and every HowTo thats put on the web also is a great deal of contribution that helps the software spreading. Beginners articles are important to put on the web since every one of us had it's beginnings and these are the sort of articles where many people decide to either use the software for a certain project or not.

As you might see, this article is not only a guide on contributing bugfixes, but also I want to motivate you to just give it a try.

... on Zend Framework

Having spent almost a year at the IRC support channel, I can tell they're really fun guys to hang around with. Of course, the Framework itself developed into a great piece of software. I do not want to discuss the up or downsides of a use-at-will framework, neither I want to recommend it over {put your favourite software here}. But what I can talk about is a little summary of the support channel's chatlogs. The widely annouced channel (which is #zftalk on Freenode) includes all kinds of concerns. One kind of people finds bugs, the other do have really clever ideas on improvements, but when you ask them to contribute its all the same: they either think it takes years to get into it, the others think they might be "not good enough for this". We sure won't force or threaten people to contribute, but what I can do is taking the fear out of it and demystify the thing, so later you might see that its actually just a few minutes to spend. Let me just loose a few words to the latter ones before we get into it: You can't destroy anything, and every idea of yours can also lead to a great improvement either realted to your concern or in a completely different area. We're glad that you take your time, even if you are completely new to ZF. Some beginners concerns already caused developers to write guides and articles that are still around and are linked at times in #zftalk...

... on contributing to Zend Framework

Contributing any code to ZF requires signing the CLA, which is an agreement that both you have the right to share any code you supply, and that you will not patent that code. This is to ensure that the frameworks codebase remains business friendly, and free to use for everyone. In fact you have to actually sign a paper, having done this you can just scan and mail or fax it. This is an important step, and none of your code will be used in any official package unless you did this.

The next step will be reading the coding & subversion standards. If you already had a look at actual ZF components code you should be familiar with the standards. Once you took a short insight (you probably wont be able to just remember all of this at once), you can check out the official SVN repository. Notice, that you, even having signed the CLA and being confirmed, do not have commit rights. So you might now ask yourself how to contribute then? All magic is taking place in the bugtracker, ZF's official Jira. All bug tickets, additions and improvements are filed as tickets here. So if you find a bug, report it here, and soon there will be a discussion in the comments section of a ticket.

Mostly all of these people, being listed by their reallife names, are also to be found on different names in the support channel, so feel free to ask them any ticket-related stuff.

The code itself will be submitted as a patch file (svn diff patchFile), and uploaded in the Jira-Ticket. This might also be done by people who do have commit rights, but one might not be sure how to fix a problem, or any question might be left. This method of code management then leaves it to the original package developer to decide whether a change should be made or it should be thought over again (might have side effects on other packages and so on).

The last yet very important point is unit tests. ZF makes heavy use of th

Truncated by Planet PHP, read more at the original (another 1916 bytes)