Changes

Jump to: navigation, search

Tree Rules

146 bytes added, 21:01, 26 June 2018
updated links to general checkin rules, added ESR 60
If you're not using [http://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview.html MozReview], or need to have more control over the order or timing of your commits (touching multiple systems, etc), you can still land code the manually into the mozilla-inbound repository. These general rules apply:
* '''All changes''' must meet the [https://developer.mozilla.org/Enen-US/Developer_Guidedocs/Mozilla/Developer_guide/Committing_Rules_and_Responsibilities general checkin rules], except you do not need to watch the tree after pushing.
* mozilla-inbound is merged into mozilla-central approximately daily.
* Please read '''[[Tree Rules/Integration| the integration rules]]''' for commit procedures and the list of sheriffs.
* 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 [https://developer.mozilla.org/Enen-US/Developer_Guidedocs/Mozilla/Developer_guide/Committing_Rules_and_Responsibilities 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.
'''<font color="orange">APPROVAL REQUIRED</font>'''
* '''All changes''' must meet the [https://developer.mozilla.org/Enen-US/Developer_Guidedocs/Mozilla/Developer_guide/Committing_Rules_and_Responsibilities 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:
* 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_Management|release manager]] team. They are also subject to the same restrictions as [[#mozilla-beta]], including string freeze and UUID freeze.
== [https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr52 mozilla-esr52] (Firefox 52.x.y ESR) and [https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr60 mozilla-esr60] (Firefox 60.x.y ESR) ==
'''<font color="orange">APPROVAL REQUIRED</font>'''
* See [[Release Management/ESR Landing Process]].
Confirm
567
edits

Navigation menu