I am so excited about the Pizza, Bugs and Fun event that is coming up that I though I would share with everyone some info to help get themselves set up and ready to participate.  There are only two main ingredients that you need.  The first is a local server environment.  The second is an SVN client.  Don't think it is too big a slice to take on.  Dig in.

Local Server Environments

A local server environment is basically a web server that you run on your local computer. Lots of people test on live web servers, but you don't have to test on a live server to participate.

WAMP - (Windows, Apache, MySQL, PHP)
For general information on what WAMP is you can check out their Wikipedia entry: http://en.wikipedia.org/wiki/WAMP, and you can compare different WAMP software on Wikipedia also: http://en.wikipedia.org/wiki/Comparison_of_WAMPs
WampServer: http://www.wampserver.com/en/download.php
You can find FAQs and Installation help here: http://www.wampserver.com/en/

MAMP - (Macintosh, Apache, Mysql, PHP)
MAMP at Wikipedia: http://en.wikipedia.org/wiki/MAMP
MAMP by living-e AG: http://www.mamp.info/en/download.html
You can find FAQs and Installation help here: http://www.mamp.info/en/dl_info.html

XAMPP - (Multi OS, Apache, MySQL, PHP)
XAMPP Project: http://www.apachefriends.org/en/xampp.html
You can find FAQs and Installation help here: http://www.apachefriends.org/en/faq-xampp.html
XAMPP is available for Linux, Windows, OS X, and Solaris.

XAMPP is the one I use on both my Mac and Windows systems, but I also like WampServer on Windows.

SVN Clients

The next ingredient for excellent pizza is to have an SVN client. This will allow you to keep your testing Joomla! files up to date as changes happen.  It will also allow you to test patches easily. Wikipedia has an excellent page with information as to what SVN is and how it is used:http://en.wikipedia.org/wiki/Subversion_(software)

EasyEclipse is a good choice for Linux, OS X and Windows: http://www.easyeclipse.org/site/distributions/php.html.  Nur Aini Rakhmawati has an excellent video tutorial on using JoomlaCode SVN with EasyEclipse here: http://developer.joomla.org/gsoc2008/16-overall-project/99-joomlacode-svn-with-easyeclipse.html

Another Windows choice is TortiseSVN: http://tortoisesvn.tigris.org/  It is available for download here: http://tortoisesvn.net/downloads.  You can find support manuals and FAQs on their site.  Details on how to work with the JoomlaCode repository are located on the Developer site: http://developer.joomla.org/code.html

With these tools you will now have the foundation or "crust" for your pizza.  Have fun!

Test this patch, make a patch, are things you hear when you report an issue or when you're working on bugs. What exactly is a patch?

A patch is a file that indicates which exact lines in which exact files should be changed.

Here's a recent patch from issue 11354 which corrected a simple typo.

Index: plugins/authentication/gmail.php
===================================================================
--- plugins/authentication/gmail.php (revision 10386)
+++ plugins/authentication/gmail.php (working copy)
@@ -87,7 +87,7 @@
 }
 }
 else {
- $message = 'curl isn\'t insalled';
+ $message = 'curl isn\'t installed';
 } 
 if ($success)

Looking more closely, we see that the patch always starts with the name of the changed file relatiive to the Joomla! root. In this case it is the file gmail.php in the plugins/authenticaion folder.

Next we see the file named again in two lines. The number in the first line represents the version of the code base or build on which the patch was created, The working copy is the copy that is changed. What do I mean by build? Every time a change is made to he codebase, that creates a new revision or build. You can find your build number in the changelog.php file in your joomla! root.

Next comes @@ -87,7 +87,7 @@ which tells us that the change will starton line 87 of the file.

Finally we see the code. The old line 87 has a – in front of it and the new line 87 has a +.

The new version of the line will replace the old line in the file.

Of course most patches are much more complex than this, but they really just are repeated instances of this structure.

So if you saw this patch file and wanted to fix your version of Joomla! all you would need to do is find line 87 of gmail.php and make that change. So if someone tells you “There's a patch on the tracker” what they are saying is that you can go download the patch and apply it to your version of Joomla!. However one thing to keep in mind is that if your version does not match the version in the code repository it is possible that that patch will not work because it depends on or impacts other parts of the code.

Now, if you're contributing a bug fix  as opposed to just reporting an issue, the ideal is to submit a patch file that you have tested. However, if you can't do that, at least give this information:

• The complete names and paths of any files changed
• The line numbers of the changes
• The old and new versions of the changed lines

However, making a patch file is even better and  is not complicated if you install a subversion client such as Tortoise or the Subclipse plugin for Eclipse.

The Joomla! Bug Squad has been going strong for about five months now, and things couldn't be better. For the most part, we've been using a manual testing technique, simply because it's fast, easy, and flexible. We've had a few people interested in unit testing, especially for maintenance procedures, but for the most part unit testing hasn't caught on.

Okay, I'll admit, even I was skeptical about the value of unit testing. I knew it had benefits, but I really wondered if all the effort required to build unit tests was really worth it. Then, I encountered an issue with JCache. The patch was an easy fix, but I had no idea how to test the patch thoroughly. Then, it occurred to me that perhaps this was a good candidate for the famed unit tests!

You've been trying to solve it for hours, no one on the forums has been able to help, the issue seems not to be covered in the documentation, and you are probably on a deadline too. Time to submit it to the tracker. After all that effort, it sure seems like a critical issue.  So, you select a priority level of high.

Then what happens? Someone from JBS goes and changes it to medium. Why did they do that? Does that mean your issue isn't important and it won't be dealt with? Are they just mean and uncaring?

Of course not. It just turns out the the development work group has pretty strict definitions of artifact priority levels.

The artifacts are prioritized according to the following characteristics:

1. High/Critical: The trunk is not working at all. Significant parts of the source are broken preventing key operations.  Examples would be login, installation, extenstion installers, javascript errors that prevent you from moving a save or similar action, etc.  Also includes the generation of Fatal PHP errors for .
2. Medium High/Major: Parts of the source are obstructing operation in a serious way or causing a major loss in advertised function. 
3. Medium/Normal: Issues that are hindering advertised behaviour but the application is still workable.  Examples would include parameters not working as advertised, language files not loading as expected, etc.
4. Low/Minor: Minor loss of function and generally annoying behaviour.  May include less common platform or browser specific problems that while they may be technically major in those environments, they represent a minority.  Also include missing translation strings.
5. Very Low/Trivial: Cosmetic problems, mis-spelled words, graphically mis-aligned object, less common issues with parameters, etc.

What does this mean?

First of all, if it is not within the first few days of a release and it doesn't involve a security issue, unless you are using subversion or a nightly build you will most likely never see a prioirty 1 (high) issue or need to report one. That's because if there are any open priority 1 issues in the codebase, there will not be a release. The same thing actually goes for prioirty 2 (medium high). A real prioirty 1 issue in an actual release is something that would trigger a new release. A priority 1 or priority 2 issue in the 1.5 branch of codebase would keep a scheduled release from taking place. This is serious, because each release contains many bug fixes and improvements, so not releasing keeps most of the community from getting those. Forcing an unscheduled release is serious too, because it means that work on other things stops while all efforts are put into getting the release ready.

The one exception would be if you discover a major security issue, but the tracker is not usually the place to report most security issues.

This doesn't mean that there are never prioirty 1 or 2 issues. Just this week there was a prioirty 1 issue (http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=11225) that had to do with an issue in the current Joomla! 1.5 source code that is in Subversion. Subversion is where all of the changes to the source code are made.

So, before you decide to mark an issue as priority 1 or priority 2, think about whether it would really warrant all of these things.

Most issues are priority 3, medium. However, some issues are priority 4 or 5 If you mark your issue as prioirty 4 or 5 does that mean it will not get fixed? Not at all.  If it's an easy to fix issue, especially if you provide a patch or proposed code, it may get taken care of right away. Some people in JBS informally specialize in language issues or CSS or other topics that are often in prioirty 4 or 5 issues. So don't feel like you need to mark something prioirty 3 for it to get attention.

The bug squad takies care of the 1.5 release which is now in maintenance mode. That means getting the 1.5.1, 1.5.2, 1.5.3, 1.5.4  etc releases ready by fixing problems that come up. The idea is to make the release increasingly stable and take care of issues that come up. At the same time, it is vitally important not to break anything that is working. That's called software regression and it's not something you want at this stage.

In the 1.5 tracker there are several common statuses, mainly: open, confirmed, pending, ready to commit.

• Open means it's reported, but it hasn't been determined for sure whether it is a real bug or a feature request ort a mistake made by a user. This can take a long time to determine, and it is important for some one reporting an issue to respond to questions the squad asks. At this point many of the new issues are related to very specific server related issues.
• Once it is decided it's an issue that can be addressed, it goes to Confirmed. That's when the JBS tries to solve it or consults with the development team about a solution.
• Once there is a proposed solution that someone is pretty confident about, a patch is created  and attached to the report. The status is switched to pending.
• In pending, people test the solution. The JBS tries to have a few different people test in different environments (versions of PHP, IIS veruse Linux etc., various browsers). The number of testers depends on how complicated the issue is, basically, but also on how likely it is to break something.
• Then when it has been tested and is okay, it goes to ready to commit, which is when one of the commiters does a really careful review and if all is okay commits the patch.

In the wiki you can see a fabulous flow chart of this as well as more details.

You don't need to be a member of the jbs to help clear up Joomla! bugs.

Iif you want to help with bug squashing, jump into the tracker where you want, you can do the open ones and try to confirm, or the confirmed ones and try to fix, or you can test the pendings.

To report about what you have done, login to joomlacode and add a comment. 

 You'll be amazed at how much impact you can have and how good it feels to contribute to the Joomla! project.

Welcome to the Joomla! Bug Squad Blog! Members may share procedures for reporting bugs or highlight important fixes coming out in a new release. From time to time squad members might also share tips with the community given issues they observe in the Joomla! forums. The Joomla! Bug Squad manages the tracker, hunts down the bugs, and make patches with fixes, 24 hours a day, 7 days a week. These are some of the hardest working members of our community. So, keep an eye on this spot - the Joomla! Bug Squad has a unique perspective worth considering.