Tree Rules
From MozillaWiki
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.
Contents
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.
- 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.
- 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
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
- All changes must meet the general checkin rules. You must check the tree before pushing, and watch the tree for failures after pushing.
- See Release Management/B2G_Landing.
mozilla-esr31 (Firefox 31.x.y ESR)
APPROVAL REQUIRED