Confirmed users
571
edits
Tree Rules/Integration: Difference between revisions
→Sheriff Duty: quick follow-up fixes might be accepted to prevent overhead of backout and reland
ChrisCooper (talk | contribs) No edit summary |
(→Sheriff Duty: quick follow-up fixes might be accepted to prevent overhead of backout and reland) |
||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
= What are integration repositories? = | = What are integration repositories? = | ||
Repositories such as [https://treeherder.mozilla.org/#/jobs?repo=autoland autoland] and [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound mozilla-inbound] are integration | Repositories such as [https://treeherder.mozilla.org/#/jobs?repo=autoland autoland] and [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound mozilla-inbound] are integration branches that merge to and from mozilla-central about once a day. They're a place where changes can land and be tested without risk of breaking the main mozilla-central trunk. | ||
= Working with integration repositories = | = Working with integration repositories = | ||
It is recommended that you use the [http://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/unifiedrepo.html Unified Firefox Repository] | It is recommended that you use the [http://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/unifiedrepo.html Unified Firefox Repository] for landing to mozilla-inbound. | ||
* https://hg.mozilla.org/mozilla-unified/ | * https://hg.mozilla.org/mozilla-unified/ | ||
Unless you're a sheriff or something has gone horribly wrong, you shouldn't need to clone the autoland repo. | |||
= What are the tree rules for integration repositories? == | = What are the tree rules for integration repositories? == | ||
* Follow the '''[https://developer.mozilla.org/ | * Follow the '''[https://developer.mozilla.org/en-US/Developer_Guide/Committing_Rules_and_Responsibilities general rules for committing]''', ''except'': | ||
** Committers are ''not'' required to actively watch the tree after pushing to an integration repository. | ** Committers are ''not'' required to actively watch the tree after pushing to an integration repository. | ||
** Checking [https://treeherder.mozilla.org/ Treeherder] before pushing is not required, but it is appreciated. If the tree is in a very broken state, you can save the sheriffs work by notifying them instead of pushing. | ** Checking [https://treeherder.mozilla.org/ Treeherder] before pushing is not required, but it is appreciated. If the tree is in a very broken state, you can save the sheriffs work by notifying them instead of pushing. | ||
| Line 29: | Line 31: | ||
= Sheriff Duty = | = Sheriff Duty = | ||
* Sheriffs will watch | * Sheriffs will watch these trees (mozilla-inbound and autoland) and back out bustage/regressions as necessary to keep it green. | ||
** | ** If code sheriffs notice a permanent task failure, they might reach out to the developer to check if the issue is simple mistake which can be fixed with a follow-up patch provided to them through Phabricator in the next 5 minutes. | ||
** The backout will be noted in the bug. The onus isn't on the sheriff to contact the developer via IRC regarding the backout. Developers who do not read all bugmail are encouraged to set up appropriate mail filters on bugs to which they are assigned, to ensure they are aware of the backout. | ** The backout will be noted in the bug. The onus isn't on the sheriff to contact the developer via IRC regarding the backout. Developers who do not read all bugmail are encouraged to set up appropriate mail filters on bugs to which they are assigned, to ensure they are aware of the backout. | ||
** If it's not possible to identify the guilty changeset, the sheriffs may | ** If it's not possible to identify the guilty changeset, the sheriffs may back out more changesets to minimize the overhead/time to fix the tree. Completely innocent pushes may be re-landed by the sheriff once the bustage is cleared or, in case of doubts, a Try server run will be requested in the bug, before the next landing. | ||
* About once a day or more, merge a green integration repository push with valid PGO results to mozilla-central. | * About once a day or more, merge a green integration repository push with valid PGO results to mozilla-central. | ||
** If the push includes compiled files or changes to configure/Makefiles it must have green PGO builds. Otherwise, the first push before it including such changes must have them. | ** If the push includes compiled files or changes to configure/Makefiles it must have green PGO builds. Otherwise, the first push before it including such changes must have them. | ||
** Also merge mozilla-central to each integration repository. Merge any large or disruptive changes from central sooner. | ** Also merge mozilla-central to each integration repository. Merge any large or disruptive changes from mozilla-central sooner. | ||
** Resolve bugs that were landed, and set the appropriate target milestone. The [http://www.graememcc.co.uk/m-cmerge/ m-cMerge tool] partially automates this step. | ** Resolve bugs that were landed, and set the appropriate target milestone. The [http://www.graememcc.co.uk/m-cmerge/ m-cMerge tool] partially automates this step. | ||
** When merging inaccessible security fixes, send email to the bug assignee and Cc the reviewer, to politely ask them to resolve their bug. | ** When merging inaccessible security fixes, send email to the bug assignee and Cc the reviewer, to politely ask them to resolve their bug. | ||