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) |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
= 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 = | |||
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/ | ||
Unless you're a sheriff or something has gone horribly wrong, you shouldn't need to clone the autoland repo. | |||
* Follow the '''[https://developer.mozilla.org/ | = What are the tree rules for integration repositories? == | ||
* 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 19: | Line 20: | ||
** It is recommended to have a separate local clone. Pull to it, apply your patches, and then push to the integration repository. | ** It is recommended to have a separate local clone. Pull to it, apply your patches, and then push to the integration repository. | ||
= Please do the following after pushing to an integration repository = | |||
* '''Leave bugs open'''. The sheriff will resolve them when they are merged to m-c. | * '''Leave bugs open'''. The sheriff will resolve them when they are merged to m-c. | ||
* '''Add the "leave-open" keyword''' if the bug should not be resolved fixed after the merge to m-c. (We're now using a new semi-automated tool - bug comments won't be seen). | * '''Add the "leave-open" keyword''' if the bug should not be resolved fixed after the merge to m-c. (We're now using a new semi-automated tool - bug comments won't be seen). | ||
| Line 29: | Line 30: | ||
* There is no need to add "[inbound]" to the status whiteboard any more, but you may still do so if it helps with tracking your assigned bugs. | * There is no need to add "[inbound]" to the status whiteboard any more, but you may still do so if it helps with tracking your assigned bugs. | ||
= Sheriff Duty = | |||
* Sheriffs will watch these trees (mozilla-inbound and autoland) and back out bustage/regressions as necessary to keep it green. | |||
* Sheriffs will watch | ** 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. | ||
= Meet the Sheriffs = | |||
The integration repositories are managed by group of sheriffs, please be nice with them. If you have any doubts or questions about the above process, you can ping any of them in #developers channel. | |||
The integration repositories are managed by group of sheriffs, please be nice with them. | |||
For the list of people to look out for, see [[Sheriffing#Meet_the_Sheriffs|Meet the Sheriffs]]. | For the list of people to look out for, see [[Sheriffing#Meet_the_Sheriffs|Meet the Sheriffs]]. | ||