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
(→What are the tree rules for mozilla-inbound?: clarify that test before pushing doesn't mean full try run for every patch) |
(→Sheriff Duty: quick follow-up fixes might be accepted to prevent overhead of backout and reland) |
||
| (19 intermediate revisions by 9 users not shown) | |||
| Line 1: | Line 1: | ||
= What are integration repositories? = | |||
mozilla-inbound | 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? == | ||
** Committers are ''not'' required to actively watch the tree after pushing to | * Follow the '''[https://developer.mozilla.org/en-US/Developer_Guide/Committing_Rules_and_Responsibilities general rules for committing]''', ''except'': | ||
** Checking | ** 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. | ||
* When can I push to | * '''Integration repositories are no replacement for [[Try]]'''. You still need to test your patches before pushing. This doesn't mean that you need an all-platforms try run for every patch, but it does mean that you should do enough testing so that you rarely cause red or orange on the integration repository. Breaking it rarely is OK. | ||
** If there is something very wrong with | ** The exception is if you are using the autoland integration with MozReview [[http://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview/autoland.html#sending-commits-to-try send your commits to the Try server automatically]]. | ||
* Push to | * When can I push to the tree? '''Always!''' | ||
** If there is something very wrong with the integration repository, a sheriff will close the tree, and your push will fail automatically. | |||
* Push to it like any separate hg repo. | |||
** 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 " | * '''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). | ||
* '''Check the assignee, platform, in-testsuite flag''' are correctly set. | * '''Check the assignee, platform, in-testsuite flag''' are correctly set. | ||
* '''You do not need to set the target milestone any more''' (if it is set already though, please check it is correct!), since the new merge script will do that for you. | * '''You do not need to set the target milestone any more''' (if it is set already though, please check it is correct!), since the new merge script will do that for you. | ||
* Add the | * Add the integration repository changeset URL to the bug. If there are multiple patches on the bug and you are not pushing all of them, please indicate which one(s) you pushed (eg: use patch -> details -> comment on patch, or else use the new per-patch checkin+ flags). | ||
* If the patch(es) had been sent to try, please include the URL, so in the case of bustage, it's easier to eliminate your push as the cause. | * If the patch(es) had been sent to try, please include the URL, so in the case of bustage, it's easier to eliminate your push as the cause. | ||
* If you backout from | * If you backout from an integration repository, annotate that in the bug. This helps sheriffs when merging. | ||
* 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. | |||
** 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. | |||
* Sheriffs will watch | ** 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. | ||
** The backout will be noted in the bug | |||
** If it's not possible to identify the guilty changeset, the sheriffs may | |||
* About once a day or more, merge a green | |||
** 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 | ** 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. | ** 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. | |||
For the list of people to look out for, see [[Sheriffing#Meet_the_Sheriffs|Meet the Sheriffs]]. | |||