kelvinluck.com

a stroke of luck

Flex bug quashing

Last weekend I joined in on the first ever Flex Bug Quash. What is a bug quash?

An event where the community comes together with one goal in mind… To quash as many bugs in one day as humanly possible. Don’t just complain, do something about it.

The idea was to allow the commuity to get involved and contribute bug fixes for the Flex framework back to Adobe. This is open source in action! As someone who has spent a fair amount of time cursing the Flex framework and it’s bugs I thought that I should get involved. It also seemed like a good opportunity to network with other Flex developers – although this aspect would have definitely been better if I was close enough to attend in person in Seattle (or one of the other hubs). At least I was in the correct timezone – some developers in Europe, Asia and Australia worked through the night!

After checking out a working copy of the entire 3.x branch of the Flex SDK from the repository I could work on getting my environment set up. The SDK has Flex Builder library projects for the framework.swc, airframework.swc and rpc.swc set up. So I set up a “BugQuash” project and linked it into the framework library project. This means I was basically monkey patching the framework.swc with the latest sourcecode from svn – including any changes I made. This allowed me to easily tackle bugs.

There was a list of bugs on the Adobe bug tracker which were marked as “SDK Community Bug Fix Candidates” – these were bugs which were considered good candidates for the community to tackle. I think this meant that they hadn’t been judged important enough to be placed on an Adobe engineer’s workload and they weren’t considered too hard or dangerous for the community to have a go at. I had a quick flick through the issues on this list and picked the first one which looked like a nice quick and simple fix.

My first bug took a little longer than I expected to fix. While it was quite simple I wanted to make sure that I was doing things correctly and putting my code in the correct places. It’s harder than simply writing code as you have to make sure you think about how any other developer might use (or abuse) the code you write. Once my code was done I generated a patch file – this was easily done with Tortoise SVN. Having signed the relevant legal documents I could then simply attach the patch to the relevant ticket in the bug tracking system.

Once the patch was on the system it needed to be reviewed by a member of the community. Chris Hill kindly volunterred and checked my code and added some extra test cases. Once this was done the bug went into a queue waiting for official Adobe code review. And once that was done my patch was given the go-ahead and committed back to the framework repository. It was very satisfying when my bug was approved and my patch was checked into SVN. I’m genuinely proud that some of my code is in the Flex framework and that I’ve added some useful functionality. And I’m fairly certain that this bug fix will save some cursing for developers when the next point release of the framework comes out!

I then picked up another bug to look at and also successfully submitted a patch for it. As a prize (along with having hopefully helped to make Flex a better place for developers) I get to display this little badge:

Overall I found the event to be very rewarding. More important than the bugs I fixed on the day is the fact that I now feel that I can contribute to the Flex framework. I’m not using Flex too much at the moment but I know that when I was using it day in, day out I would often come up against bugs. And often the fix was simple to implement. But if the fix required monkey patching or otherwise modifying the framework it wouldn’t be allowed in the project (as the project needs to build with a default Flex framework) and I’d end up using an ugly workaround instead.

Now that I know I can submit patches to Adobe and that those patches can be accepted into the framework (obviously dependant on their quality and any side effects) I am much more likely to do so. And if there are a number of similarily empowered developers using Flex day in, day out then we should see a vast reduction in the number of bugs in the Flex framework. So I think that the inaugural flex bug quash was a great success and I look forward to using a more reliable flex framework in the future.

No Comments, Comment or Ping

Reply to “Flex bug quashing”