How a Patch Becomes a Revision

Posted at August 10, 2013

If you use Mercurial, your first step would be to clone the Mozilla Central repo, create a feature/fix branch and make your changes. Once you're done making code changes, you'll want to update the main branch to catch up with Mozilla Central and then rebase your feature/fix branch. You will then want to clone B2G Inbound and pull in the changes from your branch in your Mozilla Central fork. This will ensure that your patch will likely apply cleanly to B2G Inbound. Once you get your patch to apply cleanly, submit it in the associated Bugzilla bug for review.

To get a patch reviewed, you need to edit the patch details and select the "?" in the reviewer drop-down and enter in the names of the people you would like to review the patch. Once the patch is reviewed, the bug will get "r+" (r-plused) if everything looks good. If you don't have commit access to B2G Inbound, you'll need to flag the bug as "check needed". At that point the patch will be pushed to B2G Inbound. If you do have commit access to B2G Inbound, why are you reading this blog post?

At this point, it is a waiting game. The sheriffs will eventually merge your change into Mozilla-Central. Rinse and repeat.

If you use Git, you'll want to clone the Gecko.git repo from github.com and work there. Your patch will still need to be rebased to the master branch and then made to apply cleanly to the B2G Inbound repo before submitting it to Bugzilla for review.