As our recent development focus shifting from Firefox OS to Firefox, we need to contribute to gecko repository directly instead of contributing to Gaia repository on Github. The most of the works are related to Javascript. The main change is the workflow and API difference. In Gaia we work between Bugzilla and Github; In gecko, we have Bugzilla and mozReview.
Once you have setup the environment, the workflow could also be based on git(or hg), and most things are dealt automatically. Mozilla is a pretty open workplace so that I can share my workflow with the world. Here is a reference to how I did for per patch/weekly/per setup/one-time workflow.
Do it One time
To become a mozilla committer, read https://www.mozilla.org/en-US/about/governance/policies/commit/
Create Bugzilla API keyhttps://bugzilla.mozilla.org/userprefs.cgi?tab=apikey and ssh key https://login.mozilla.com/ssh_keys_index
Do at every Setup
You may check MDN as a start point, with Developer Guide https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide and especially the source code page https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Source_Code
I will do the setup flow every time I got a new laptop.
1. Update git
Use the PPA from the maintainers of git on Ubuntu:
$ sudo apt-add-repository ppa:git-core/ppa
$ sudo apt-get update
$ sudo apt-get install git
2. Install git-cinnabar
Gecko itself managed via mercurial, we need install git-cinnabar to help us deal with mercurial codebase via git.Check http://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview/install-git.html#mozreview-install-git `
$ sudo apt-get install mercurial
$ git clone https://github.com/glandium/git-cinnabar.git
Then set git-cinnabar into system PATH,
$ gedit ~/.bashrc
export PATH=$PATH:absolute_path_to/git-cinnabar
$ . ~/.bashrc
And do git cinnabar download to get the faster helper.
Then follow `Mozilla: A git workflow for Gecko development to checkout gecko via git.
Make sure you follow the Firefox build guide https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build to setup Firefox build environment.
You can install style check related libraries via the following command:
$ ./mach eslint --setup
You may want install mozreview which improves the overall experience of review with Bugzilla http://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview/install.html
$ ./mach mercurial-setup
Will clone version-control-tools into ~/.mozbuild/version-control-tools. We need update system PATH
$ gedit ~/.bashrc
export PATH=$PATH:absolute_path_to/git-cinnabar:/path/to/.mozbuild/version-control-tools/git/commands
$ . ~/.bashrc
$ git config --global bz.username [email protected]
$ git config --global bz.apikey [your bugzilla key]
$ git config --global mozreview.nickname gasolin
$ git mozreview configure
Then, run bootstrap script to install required build environment,
$ ./mach bootstrap
Then, the most time-saving advice: setup mozconfig for artifact builds if possible. When you only work for front-end related work (non c++), Artifact build will download compiled platform code to save you lots of build time.
Weekly workflow
Previously build takes more time, I usually do the following command only twice a week if necessary. But now we can use artifact build, which is pretty fast and can be done many times a day.
We need update Gecko repository regularly:
$ git remote update
Then merge recent updates into current repo with
$ git rebase central/default
Checkout a new bug and then rebuild the stack,
$ ./mach build
The command will compile the whole gecko.
Per patch workflow
When I work on a new bug, I'll checkout a new branch (on mac)
$ git checkout -b bugxxxxxxx central/branches/default/tip
or (on Ubuntu)
$ git checkout -b bugxxxxxxx mozilla/central
Usually, the bug is focused on a component of gecko, such as browser/components/customizableui. To make .js/.jsm changes work, we don't need to rebuild gecko. But to make some C++ code or new test code works, we need to rebuild this part of source via
$ ./mach build browser/components/customizableui
Once we have some progress for the patch, we can test code via the command:
$ ./mach test browser/components/customizableui/test
You need to make sure you've followed the JS code style https://wiki.mozilla.org/DevTools/CodingStandards#Code_style and CSS code style https://wiki.mozilla.org/Firefox/CSS_Tips. Do the eslint test before commit to make sure the patch does not contain some obvious syntax error.
$ ./mach eslint browser/components/customizableui/test
Once the patch is ready, commit it as normal git commit, with a structured syntax:
Bug xxxxxxx - description. ;r=?reviewer_bugzilla_alias.
Then, use git mozreview command to push the commit onto Bugzilla for review.
$ git mozreview push
You can use try chooser http://trychooser.pub.build.mozilla.org/ to select test suites that run automatically on the test server. Treeherder is Mozilla's test server hosted on AWS (Amazon Web Service). Push code there and everyone will have the same base to validate if your code works well on anyone's computer.
The reference try script (credit from :Gijs) for browser/component is
try: -b od -t none -p win32,win64,macosx64,linux,linux64,linux64-asan -u mochitest-bc,mochitest-e10s-bc,marionette,marionette-e10s
You can manipulate the script based on what you need to test.
If you like to file a bug
- Assign priorities when filing new bugs that you're going to work on in the component.