Being a fan of Python, I am also trying to work on some Mozilla Release Engineering bugs, but run into problems trying to replicate the dev environment used. This area, while interesting, is not as well developed in terms of documentation or process for outside contributors; their wiki information on setting up a dev environment is somewhat geared towards Mozilla employees.

But while I haven’t made any real headway on any release engineering bugs yet, I do have a partial dev environment up so that I can attempt to tackle a subset of their bugs, mainly the ones that don’t rely on having permissions to Mozilla’s massive build infrastructure. I also want to get involved with Autoland after reading Lukas Blakk’s (a Mozilla Release Manager) blog post on Autoland.

All in all, I feel like I am well on the way to becoming a full-fledged Mozilla contributor.

I use Firefox everyday and wanted to contribute to its source code, for bragging rights if nothing else. And Mozilla makes it really easy to start. They have a Developer’s Guide that tells you everything you need to get started. There is a lot of information there though, and some of it is slightly outdated, so it can still be confusing and make you feel lost. Here are the steps I took to submitting my first patch to Firefox:

1. I compiled Firefox following these build instructions. It took about 75 minutes on my machine (Intel Core2 Quad Q9550 w/ 4GB RAM)
2. I looked for a bug to work on in Bugzilla. Mozilla has a list of good first bugs for newbies like me. I read through that list but didn’t find anything that immediately caught my eye. I just continued browsing Bugzilla until I saw a new bug that sounded simple enough for me to fix. (I later found a mentored bug list which contains bugs with a designated mentor that you can go to for help.)
3. This was the hardest part – studying the source code to figure out where the bug should be fixed. Until now, I didn’t know Firefox used Javascript as well as C++. The codebase was massive and I had no clue where to start. I knew my way around C++, but was lost in Javascript and its associated XUL/XML files. I asked for help on the #developers channel on the Mozilla IRC server. People there are very friendly and extremely helpful. In addition to pointing me to possible places to start in the code, they also introduced the MXR tool to me. MXR allows you to search through the source code by text or by identifier (variables, classes, types, etc.). I now had some starting points from which to start debugging.
4. The 2nd hardest part – figuring out how to debug. There’s a whole section on debugging Mozilla projects. I would have like to configure debuggers for C++ and Javascript, but I found the simplest way to get started was to just look at the debug output logs. The C++ log output uses a different mechanism than the Javascript output.

   For Javascript, I just inserted dump() statements to trace through the code and output variable values. The dump output appears on the console when you start firefox with the “-console” option.

   The C++ output was a little trickier. I saw all these PR_LOG() calls throughout the code, but couldn’t figure out where the output was going. With help from #developers, I was able to enable these logs statements. I had to recompile Firefox with debug on and set environment variables NSPR_LOG_MODULES and NSPR_LOG_FILE to start the C++ logging. The PR_LOG() output will go to the file specified in NSPR_LOG_FILE.

5. Having the edit-compile-debug cycle down, I was now on more familiar ground. I found a potential fix for the bug and created a patch for it.
6. I read that a patch should be tested locally before being submitted for formal test and review. Again, there’s documentation on testing your patches, but it was daunting. I asked for help again on #developers. Someone told me in my case, I just had to run “mochitests” and only on the modules I changed. I did so and submitted my patch and test results for both formal automated testing and review on Bugzilla.
7. I don’t have privileges on the Mozilla testing server (Try Server), so I asked someone on IRC to help me with this. jdm on #developers did so for me (thanks!).

As of last night, the automated test passed (I think) and I’m awaiting review and acceptance and/or comment on my patch. Then I can say I have code in Firefox!

]]> http://ewong.me/how-i-became-a-firefox-contributor/feed/ 0 http://ewong.me/open-source-hacking/ http://ewong.me/open-source-hacking/#comments Sun, 04 Mar 2012 21:41:36 +0000 Eric http://ewong.me/?p=45 Continue reading →]]> I’ve been wanting to contribute to an open source project for quite a while now, but haven’t gotten around to it until recently. Over the past year or so, I’ve been perusing open source projects that I use and seeing how each community works. I concentrated mostly on projects that I use extensively, among them, Rockbox, Django , SparkleShare and Mozilla (Firefox).

Rockbox is a great replacement for the firmware on my MP3 player. I prefer the interface and it provides a lot more features. I even write firmware in my dayjob, so Rockbox was originally the first project I wanted to contribute to. A lot of Rockbox development discussion take place on their development mailing list which I started subscribing to. That’s when I decided it was not for me. A lot of chippiness and arguing occur there and I wanted to avoid that. I know open source project development is sort of known for harsh abrupt discussions, but I knew more developer-friendly communities exist and wanted to find one of these to contribute to first. Why take abuse when it’s something I want to do for fun?

Django has great documentation, and that’s also the case with regards to contributing to it. They have an “easy pickings” list of easy first bugs that newbie developers can tackle. I hope to contribute to Django some day because I think it is a very useful project, but some things I came across with SparkleShare and Mozilla made it easier to start contributing to them instead.

SparkleShare is an open source version of Dropbox. Its Windows client is still very much in its infancy, but it works well enough for me. I came across a problem in trying to use it with some non-default settings though, and was able to fix it myself as I described here. My fix was accepted into the main project. The reason I was able to so easily contribute right away is because they are hosted on GitHub. GitHub makes it extremely easy to contribute to a project. I just forked the repository, made my fix, and had them pull my changes. I’ve since went on to make minor enhancements to their web client, SparkleShare-Dashboard, as well.

Though I successfully found an open source project to contribute to, for reasons of my own, I wanted to work on a more well-known and challenging project. And everyone knows Mozilla Firefox. Like Django, Mozilla has great intro documentation as well for anyone who wants to contribute. To start with, I downloaded the Firefox source code and compiled it by following their clear instructions here. Then, I looked for a bug that sounded simple enough for a newbie to start with. Mozilla also has a good-first-bug list similar to Django’s easy pickings list. Nothing caught my fancy there though. So I started browsing through new bugs recently entered and found one that sounded simple enough for a first-timer. I’ve been working on it on and off since, whenever I have some free time. The majority of the effort has been figuring out the best way to debug the code, how to configure the debug logging and where the log statements appear. Mozilla has excellent (though some out-dated) documentation on this and their developer IRC channel has been a big help. I’m 95% of the way to a patch that I will then submit and test (a whole other learning experience).

I’ve had a good time contributing to these two open source projects so far and plan to continue as time allows. I look forward to being able to (soon) say code I wrote is in Firefox.

]]> http://ewong.me/open-source-hacking/feed/ 1