Firefox Marketplace Beginner Bugs – My First Pull Requests

Published in Open Source

Now that my projects were setup and in good working order, I decided that this week I would try to find some beginner bugs to fix that would give me a bit of an introduction to the flow of submitting a bug fix and getting it accepted. The Zamboni and Fireplace projects are quite substantial so I knew that I would have to take it slow so that I wouldn’t get frustrated with not knowing where certain components lived or how they worked.

To start out, I scoured the list of beginner bugs for the Marketplace project. At the time of writing there are only 9 of them. These bugs have been specifically marked as ‘contribute’ to indicate that they would be easy for anyone to tackle (even me!). One bug in the list mentioned that somewhere in the site there was a couple links that pointed to some less than helpful information and it was suggested that these links point somewhere else. I thought that this would be the perfect candidate for my first contribution.

First Bug: Update Some Link Text

I started up my development server and it took me a little bit of time to even find the location of the links that I was supposed to be changing. The main place to change was on the app submission page, which developers must access to validate their apps and begin the submission process. To access the app submission page, I was required to sign in with a system called Persona. Mozilla’s Persona system is a way to authenticate with websites using any existing email address. The nice thing about the system is that you can use the same email and password combination on any website that has it implemented.

Registration and e-mail confirmation for Persona was simple but I still was not being authenticated successfully. I ended up having to set a proper SITE_URL in my marketplace settings (settings_local_mkt.py) file.

SITE_URL = ‘http://0.0.0.0:8000’

After restarting my development server (Note: any change to the settings file requires this), I was able to access the app submission page and see exactly where the text change had to occur. Finding the spots in the source code that I needed to change was quite simple using a quick search. Once I was happy with the change, I decided that I would submit my code for review.

One thing that I didn’t do when I started working on the bug fix was create a new git branch. I rectified this quite easily by creating the branch and checking it out:

git branch bug-957393

git co bug-957393

I pushed this branch up to my forked repository (I use the official Mac Github client to review my changes before pushing) and ventured over to the official Zamboni repository in order to create my pull request. Github has a great feature after pushing a new branch that asks you if you want to create a pull request into master, so I did exactly that. I gave a short description of the bug and linked to the appropriate ticket in Bugzilla and opened my first pull request up to public viewing.

Even though this bug was no technical feat, I will admit that I was a bit nervous putting it out there to be scrutinized. Have seasoned developers pick apart your code can be scary and refreshing at the same time. After all, I am in it for the learning experience. Within less than 30 minutes, one of the project’s developers left some comments on what I had done. He asked me to change some of the language that was used and to change the URLs so that they were not pointing to a specific locale (en-US in this case). I quickly made those changes and pushed back to the branch. I waited for a little bit thinking that I might get another reply right away but decided to pack it in after about an hour.

The pull request for this bug can be found here.

Second Bug: Remove Payment Status Page

The next day, still with no additional feedback, I decided to try to tackle another of the beginner bugs that I saw in the list. I had actually stumbled across the location of the bug fix when I was working on the first one. This bug, again quite trivial, consisted of removing a page in the developer hub that talked about payment statuses and to link to a new page in its place on Mozilla Developer Network (MDN). I removed the code for the old page and setup a redirect to the new page in case anyone was externally linking to it. I then submitted a pull request using the same process as the first bug (but on a new branch off of master).

I received some feedback again quite quickly, this time from a Mozilla developer from Paris. He asked me to ensure that my change was tested properly since it looked like it wasn’t actually being tested before. Luckily, he pointed me to the right file so adding the redirection test was easy (there were lots of other redirects already being tested). One thing that I had to figure out was how to run individual tests since I knew from experience that the entire test suite took a very long time. In the testing section in the Zamboni documentation, I found that they supply a Makefile for easily running tests and I was able to execute the following command to run only developer hub tests:

make SETTINGS=settings_local_mkt ARGS='--verbosity 2 zamboni.mkt.ecosystem.tests.test_views:TestDevHub' test

My added test was green so I submitted that change and got asked to make a small language change, which I committed as well. After a few back and forths, I was told that my changes on the second bug looked good and that I should squash my commits into a single one so that it can be merged into master. I had heard about this squashing process before just from browsing open source project issues but I had never actually done it before. From what I understand, squashing a bunch of commits into a single commit is done for cleanliness purposes so that the repo’s history looks a little better to the eye. Some thorough searching led to this post that explained the exact process of how to squash several commits into one. I followed the steps outlined and pushed back up the repository. I have also done this for my first bug in anticipation of getting the pull request merged!

You can check out my second pull request here.

The Waiting Game

Now all that is left to do is wait. Well, that and find some more bugs to tackle! I would really like to choose bugs that will enhance my understanding of the projects but I suppose that will really come with time.

UPDATE: My first pull request was accepted and merged into master! Soon enough my tiny contribution will be in use on the Firefox Marketplace. Now that’s cool!


Written By

Andrew Halligan

Published January 17, 2014