How to contribute

mozilla/gecko-dev is a mirror. You cannot land patches by opening a pull request against this repository; PRs to gecko-dev are not reviewed. Patches are landed via Mozilla's Phabricator → Lando workflow into mozilla-central, and the change appears here automatically.

This page is a fast onboarding for that workflow. The canonical guide is the Firefox Contributors' Quick Reference.

The process at a glance

graph LR
    File[Find a bug<br/>bugzilla.mozilla.org] --> Clone[Clone mozilla-central<br/>via hg or git]
    Clone --> Build[mach bootstrap<br/>mach build]
    Build --> Edit[Make changes locally]
    Edit --> Test[mach test, mach lint]
    Test --> Submit[moz-phab submit<br/>review on Phabricator]
    Submit --> Land[Lando lands to mozilla-central]
    Land --> Mirror[gecko-dev auto-updates]

Step by step

1. Find a bug. All work is tracked in Bugzilla. New contributors look for [good first bug] tags. Comment on the bug to claim it; assign it to yourself when ready.
2. Get the source. Mozilla now offers both Mercurial (hg.mozilla.org/mozilla-central) and Git checkouts. The Git option uses Mozilla's git-cinnabar / unified bridge. For most contributors today, hg clone https://hg.mozilla.org/mozilla-central is still the official path.
3. Bootstrap. Run ./mach bootstrap once to install toolchains. It writes ~/.mozbuild/.
4. Build. Optionally create a .mozconfig. Then ./mach build.
5. Run. ./mach run.
6. Make your change. See development workflow and patterns and conventions.
7. Test. Run targeted tests with ./mach test path/to/test. Run linters with ./mach lint --outgoing. See testing.
8. Commit with the right message. Format: Bug NNNNNN - short description r=reviewer. The Bug NNNNNN prefix is mandatory and links the commit to Bugzilla. The r= flag is filled in once a reviewer is assigned in Phabricator.
9. Submit to Phabricator. Install moz-phab. Run moz-phab submit from your branch.
10. Iterate on review. Reviewers leave comments in Phabricator. Update with moz-phab submit again.
11. Lando lands the patch. Once the reviewer marks the revision Accepted, you (or they) trigger Lando, which lands the patch on mozilla-central (or another branch if specified). The commit shows up in gecko-dev shortly after.

Repository conventions

• Bug-prefixed commit messages are required. Patches without Bug NNNNNN cannot be landed.
• Commit-per-logical-change. Phabricator and Lando work best with a stack of small commits; avoid squashing.
• No GitHub PRs. This mirror does not accept them.
• r= and a= markers. r=alice (review by alice), r=alice,bob (multiple reviewers), r=#component-reviewers (group review). a=release is for release-management approvals on branches.
• DONTBUILD. Append DONTBUILD to commits that don't affect any build artifact (e.g., docs-only changes), to skip CI.
• CLOSED TREE. Used by sheriffs to override the closed-tree gate when landing fixes for tree breakage.

Module ownership

The file mots.yaml and the Mozilla module ownership system define which engineers own which parts of the tree. The mots tool (tools/lint/mots/ and adjacent) keeps the file consistent. When picking reviewers, look up the relevant module's peers.

For per-directory bug-component mappings, look at the with Files(...): BUG_COMPONENT = (...) clauses scattered through moz.build files. The top-level moz.build shows examples.

Definition of done

• All relevant tests pass locally and on try.
• ./mach lint --outgoing is clean.
• The change has at least one Phabricator review marked Accepted.
• The commit message follows the format above and references the bug.
• For UI changes, screenshots are attached to the bug or revision.
• For new features behind a pref, the pref default is correct for the channel (Nightly / Beta / Release).

Sub-pages

• Development workflow
• Testing
• Debugging
• Patterns and conventions
• Tooling