The Mentality of a Bug Quasher

As BugQuash is picking up steam and people are checking out Adobe’s JIRA bug base and trying to patch bugs, many people are also finding that patching bugs isn’t always easy. Heck, I have turned in a handful of patches and only had one go through. Though with people trying to get into it I thought I would try to give some pointers as to creating a bug report, finding a bug to patch, finding the problem, patching the code, and finally submitting your patch.

Creating a Bug Report
Many times when helping others with development/programming we will come across some strange problems with the Flex SDK that can only be explained as “a bug”. When this happens I always have the same response “dude, no idea what is going on, file a bug”. Helpful huh? But seriously, file a bug.

Now I’m not going to show you how to enter in information into JIRA, that is obvious to anyone. What I AM going to do is tell you the things that bug quashers are looking for to get your bug fixed.

1. It starts with a good summary. This isn’t time to get creative, be very specific as to the problem and what component the bug is connected to. The reason for this is because some quashers have looked into specific components and feel more comfortable with these components. Highlight your component and get it picked.

Bad: CurrencyFormatter (seriously, that is someone’s real summary)
Good: After filtering datagrid’s dataprovider (arraycollection) not deselecting selectedItem (great job, Justin J. Moses)

2. Pictures are always worth a thousand words. Take pictures of your bug (if it’s visual). This is very important because quashers need to be able to SEE the problem and accurately recreate the problem.

3. Break down your problem to the smallest possible elements. You should probably do this even before you think that your bug is a bug. I have seen too many bugs that are almost unrecreatable without actually recreating the bug author’s entire application. For all we know the bug is in everything else, not in the Flex SDK. Break down the problem and isolate the issue to the smallest possible amount of code.

4. Make a test case! Yes, HELP THE QUASHER by providing the code it takes to reproduce the problem. This is probably the most helpful thing you can do to get your bug quashed. I am sure that you don’t want to take the time to make this test case, but just do it. I was surprised how many developers just put the error information or just a few sentences for their “bug” with nothing else to help reconstruct the bug instance.

5. Fill in all the information in JIRA. The last part is simple, fill in all the information that JIRA asks for. Steps to reproduce, expected and actual results, sdk version, etc. Just fill it all in and I bet you that your bug will get fixed on the quick.

Vote for my bug! If you feel that your bug is that important sell it up, and get others to vote on your bug. With enough votes your bug will gain attention and be pushed to the top of the bug heap.

Finding a Bug To Patch
I know I know, the JIRA system is slow to respond, but you just need to deal with it and find yourself a bug. Start by looking in the “SDK Community Bug Fix Candidates”. This can be found after you login at the JIRA home page in the Saved Filters. These bugs are the one’s that Adobe feels are best for the community to fix. As you are browsing through the bugs make sure to find a bug with a great code example that helps simplify your effort reproducing the bug. Next, find something that interests you. Some of these bugs are NOT FUN, and you don’t want to get bored with the problem without really fixing it. Finally, when you think you’ve found your special little bug, make sure to enter in the comments that you are working on this bug. So no other community members spend the time on this bug.

Finding the Problem
This is the hardest part, but I will tell you one mantra that may help, “Is this the real problem?” Just keep asking yourself this because I can promise you that there are many ways to make the problem bug not show back up, but only one way to truly solve the problem. For a real example let me give you the solution to my accepted patch (shameless bragging I know, but this will explain my point).

The combobox drop down list that is generated wasn’t scaling in the same way that the combobox component scaled. So if you scaled up the container over your combobox (let’s say times 2), the drop down list stayed at the same size with no scaling. Not cool. As I was looking through the code to find the root of the problem I found the spot where the drop down list was being created and I also found this code there to pass on the combobox’s scaling.

The obvious intention was to pass on the scaling of the combobox. However, if you scaled the container ABOVE the combobox, the combobox’s scale would be 1, the container’s scale would be 2, and the drop down list being created would only be 1. Not 2, therefore the scaling would be wrong since the drop down list isn’t part of the current visual chain as it’s a popup. Scaling fail.

One possible solution would have been to look for the combobox’s parent and getting it’s scaling and passing that down if the scaling of the combobox’s scale was 1. Yes, dumb I know but this would have solved the test case and I could have pushed in my patch. But what happens if the parent’s parent was scaled, or it’s parent, or the entire application?! This wouldn’t “solve the real problem”. Thinking a bit more I took the transformation matrix that would describe how the combobox was being scaled (be it from the parent, parent’s parent, application or anything else) and took the scaling properties from the matrix to be applied to the actual drop down list.

Simple looking fix, but took more than a bit of time to find, and this solved the “real problem”. Sending in the patch I knew that this bug was a winner.

Patching the Code
If you set up your development environment correctly this part is really easy. Using eclipse you can create a library project out of the Flex Framework and then just make your code changes right to the framework. Then just run your testing app with the recompiled library. It’s that simple, make your code change, rebuild the library, run the test. When you feel that the solution solves the true problem and you have tested your solution, I would put money down that your bug will be accepted. Good luck, hopefully Alex doesn’t check your patch – he’s notorious for turning down solutions, but I respect him more for that.

Submitting Your Patch
When you are ready to go, it’s time to make a difference (diff) file with your svn client. For my development environment I have svn in my computer and run it from terminal (I’m a mac). I just go to the current Flex SDK folder that I am working on and run the following line in terminal.

This will create a patch file on my desktop with my specific bug name. The reason behind putting in your bug number is so that adobe doesn’t have a million files called “bug.patch” or the like. Check the resulting text file and make sure the file only includes changes related to your bug. Remove any parts that are extraneous so that your patch can quickly be run in the other svn programs without messing with property files or other components that aren’t related to the EXACT bug. Once this is down just attach the patch to the bug in JIRA.

Done! Now you just have to wait for Adobe to accept your amazing patch. Let me know how it goes and good luck!

Bugquash Plug
In case you haven’t already check out Bugquash.com and JIRA with Adobe. Find a bug, patch a bug, show that you are one amazing Rockstar by proudly showing off your BugQuash badge. Finally, do it so that you can join the community and help the Flex SDK!