: Etherpad users! We are developing an extension that will allow you to create pages from etherpads quickly and easily. Please visit our sandbox and help us test it.

Tree Rules

From MozillaWiki
Jump to: navigation, search

For comm-central tree rules, see this page.

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

Looking to add a new platform/job type to Treeherder? See Sheriffing/Job_Visibility_Policy.

mozilla-central (Nightly channel)

  • In order to increase the reliability of our primary repository, direct pushes to mozilla-central must now only be for one of the following reasons:
    • Merging from an integration/team/project repository (there is no restriction on who may make these merges) [a=merge].
    • Automated blocklist / HSTS preload list updates [a={blocklist-update,hsts-update}].
    • For the resolution (ie: backout or follow-up fix) of critical regressions (eg: top-crashers or other major functional regression) that will result in a Nightly respin or must make the imminent scheduled Nightly at all costs [a={backout,topcrasher,respin,...}].
    • Anything else for which common sense (or asking in #developers) says is an appropriate reason for a direct landing on mozilla-central [a=something_descriptive].
  • If your patch is eligible for direct-landing on mozilla-central:
    • Use the a=reason examples given above, to bypass the Mercurial hook used to prevent accidental pushes. Note: That whilst we are using the "a=" syntax (since that's all the hook supports for now), this is unrelated to the "release-driver approval request" process - so please do not request approval from them in Bugzilla.
      • Note if merging into mozilla-central, and your push didn't generate a merge commit (and so you have nowhere to put the "a=merge" to get past the hook), then either temporarily set the tree state to OPEN, try merging a different integration repo first (which may need a merge commit), or add an empty mq commit on top with an appropriate commit message.
    • Changes must meet the general checkin rules.
    • You must check the tree is green before pushing, notify the sheriffs in #developers and then watch mozilla-central for failures.
    • Set the Target Milestone field in Bugzilla to the current Nightly version after landing a bug fix on mozilla-central.
  • All other changes must instead land via one of the integration branches and will then be merged into mozilla-central once green (these merges occur typically 1-2 times a day on the last complete green push).
  • Please ask in #developers on IRC if you have questions.

Integration Branches

Land patch - go home.jpg

The following rules apply to integration branches managed by the sheriffs, including mozilla-inbound, b2g-inbound, and fx-team.

  • All changes must meet the general checkin rules, except you do not need to watch the tree after pushing.
  • These branches are merged into mozilla-central approximately daily.
  • Please read Tree Rules/Integration 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. Exception: If patches only make changes to tests, test harnesses or anything else that does not affect the shipped builds, they may land with self approval (use a=testonly, a=npotb etc).
  • Patches nominated for aurora should:
    • not change any localizable strings.
    • 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 the release manager team.
  • 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. Exception: If patches only make changes to tests, test harnesses or anything else that does not affect the shipped builds, they may land with self approval (use a=testonly, a=npotb etc).
  • Patches nominated for beta should:
    • not change any localizable strings.
    • not change binary interfaces or otherwise break add-on compatibility. (In particular, they should not make any change to an XPIDL interface that requires a UUID change.)
    • 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.
  • Approval requests will be processed by by the release manager team.
  • 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. Exception: If patches only make changes to tests, test harnesses or anything else that does not affect the shipped builds, they may land with self approval (use a=testonly, a=npotb etc).
  • 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 the release manager team. They are also subject to the same restrictions as #mozilla-beta, including string freeze and UUID freeze.

mozilla-b2g34_v2_1 (and other B2G branches)

APPROVAL REQUIRED

mozilla-esr31 (Firefox 31.x.y ESR)

APPROVAL REQUIRED