Tree Rules

For comm-central tree rules, see this page.

Not sure which Firefox version is on which branch today? See RapidRelease/Calendar.

mozilla-central (Nightly channel)

• APPROVAL REQUIRED until April 24 to help stabilize Fennec/NativeUI. See the discussion thread for context.
  • Bugs with blocking-fennec1.0 (except "soft" blockers) can land with a=blocking-fennec.
  • Buth with tracking-firefox14+ can land with a=tracking-firefox.
  • Bugs whose whiteboard contains either sg:high, or sg:crit can land with a=security.
  • Changes that are not part of the Native Fennec build also have blanket approval to land. This includes:
    • Test-only changes (a=test-only)
    • Desktop-only or platform-specific changes (a=desktop-only, a=windows-only, a=b2g-only, etc.). This only covers patches that touch browser/*, widget/windows, widget/gtk2 or widget/cocoa at the Mobile Team's request.
    • Changes that are not part of any build (a=npotb).
  • For all other changes, use the approval-mozilla-central? flag to request approval, and leave a comment with the reasons for your request. Release drivers will decide which bugs are sufficiently low-risk and/or time-sensitive.
  • Non-approved changes can land on the Birch project branch, which will follow the same process as mozilla-inbound except that changes will not be pushed to mozilla-central until after April 24.
• All changes must meet the general checkin rules. You must check the tree before pushing, and watch the tree for failures after pushing.
• Set the Target Milestone field in Bugzilla to the current Nightly version after landing a bug fix on mozilla-central.
• Please ask in #developers on IRC if you have questions.

mozilla-inbound

• APPROVAL REQUIRED until April 24.
  • See the mozilla-central section above for approval guidelines.
• All changes must meet the general checkin rules, except you do not need to watch the tree after pushing.
• This tree is merged into mozilla-central approximately daily.
• Please read Tree Rules/Inbound for commit procedures and the list of sheriffs.
• Ask in #developers on IRC if you have any questions.

mozilla-aurora

APPROVAL REQUIRED

• All changes must meet the general checkin rules. You must check the tree before pushing, and watch the tree for failures after pushing.
• Patches must have the approval-mozilla-aurora+ flag in Bugzilla. To request approval, set the approval-mozilla-aurora? flag on the patch you wish to check in.
• Patches nominated for aurora should:
  • have tests, or a strong statement of what can be done in the absence of tests.
  • have landed in mozilla-central to bake on the nightly channel for a few days.
  • have a comment in Bugzilla assessing performance impact, risk, and reasons the patch is needed on aurora.
• Approval requests will be processed by release drivers in the weekly Firefox/Channels meetings.
• Set the appropriate status-firefoxN flag to "fixed" after landing a fix on the Aurora branch.

mozilla-beta

APPROVAL REQUIRED

• All changes must meet the general checkin rules. You must check the tree before pushing, and watch the tree for failures after pushing.
• Patches must have the approval-mozilla-beta+ flag in Bugzilla. To request approval, set the approval-mozilla-beta? flag on the patch you wish to check in.
• Patches nominated for beta should:
  • have tests, or a strong statement of what can be done in the absence of tests.
  • have landed in mozilla-central to bake on the nightly channel for a few days.
  • have a comment in Bugzilla assessing performance impact, risk, and reasons the patch is needed on beta.
  • not change binary interfaces or otherwise break add-on compatibility.
• Approval requests will be processed by release drivers in the weekly Firefox/Channels meetings.
• Set the appropriate status-firefoxN flag to "fixed" after landing a fix on the Beta branch.

mozilla-release

APPROVAL REQUIRED

• Patches must have the approval-mozilla-release+ flag in Bugzilla. To request approval, set the approval-mozilla-release? flag on the patch you wish to check in.
• In the normal development process, no changes will land on mozilla-release except regular merges from mozilla-beta every six weeks.
• Changes to the release branch are limited to urgent "chemspills" like zero-day security vulnerabilities and other unplanned emergencies. Any changes to this branch will be directly overseen by release drivers.

mozilla-esr10 (Firefox 10.0.x ESR)

APPROVAL REQUIRED

• See Release Management/ESR Landing Process.

mozilla-1.9.2 (Firefox 3.6.x)

APPROVAL REQUIRED

• patches must have been checked in and "baked" on mozilla-central,
• patches must have approval1.9.2.x+ (for whatever value of x is relevant).
• Set the "status1.9.2" flag to the relevant "fixed .x" value when the patch has been checked into the branch
• Patches nominated for approval1.9.2.x should:
  • have tests, or a strong statement of what can be done in the absence of tests
  • have landed on trunk and baked for a few days (at least)
  • have an assessment of performance impact
  • have an assessment of risk

Please see #developers or today's Sheriff if you have questions.

The branch approval queue is being monitored by branch drivers, all of whom are usually available on IRC.