Tree Rules/Integration

What are integration repositories?

Repositories such as autoland and 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 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.

What are the tree rules for integration repositories? =

• Follow the general rules for committing, except:
  • Committers are not required to actively watch the tree after pushing to an integration repository.
  • Checking 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.
• 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.
  • The exception is if you are using the autoland integration with MozReview [send your commits to the Try server automatically].
• 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.
• 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.
• 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 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 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.

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.
  • 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.
  • 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 mozilla-central sooner.
  • Resolve bugs that were landed, and set the appropriate target milestone. The 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.

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 Meet the Sheriffs.