Tree Rules/Integration

What is mozilla-inbound?

mozilla-inbound is an integration branch that merges to and from mozilla-central about once a day. It's a place where changes can land and be tested without risk of breaking the main mozilla-central trunk.

• http://hg.mozilla.org/integration/mozilla-inbound
  • To speed up the cloning you can use the bundle (instructions) or see this blog post.
• http://tbpl.mozilla.org/?tree=Mozilla-Inbound

What are the tree rules for mozilla-inbound?

• Follow the general rules for committing, except:
  • Committers are not required to actively watch the tree after pushing to mozilla-inbound.
  • Checking tinderbox 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.
• Inbound is no replacement for Try. You still need to test your patches before pushing.
• When can I push to mozilla-inbound? Always!
  • If there is something very wrong with mozilla-inbound, a sheriff will close the tree, and your push will fail automatically.
• Push to mozilla-inbound like any separate hg repo: it is recommended to have a separate local clone. Pull to it, apply your patches, and then push to mozilla-inbound.

Please do the following after pushing to inbound

In order to save time for the people doing the merges, after pushing to inbound please:

• Leave bugs open. The sheriff will resolve them when they are merged to m-c.
• Add the inbound 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).
• Set the target milestone (unless an aurora migration is due within 24 hours).
• Check the assignee, platform, in-testsuite flag & other fields are correctly set.
• If this has been sent to try, please include the URL, so in the case of bustage, it's easier to eliminate your push as the cause.
• Optionally add "[inbound]" to the status whiteboard for bugs that have been fixed on mozilla-inbound.
  • Please do not do this any more, as it means the merges take even longer - and was not being done consistently anyway. Just leave the inbound changeset in a comment on the bug instead.
• If the bug should remain open after the inbound changeset makes it to mozilla-central (e.g. patches left to land or other work needs doing), please add "[Leave open after merge]" to the bug whiteboard.
• If you backout from inbound, annotate that in the bug. This helps sheriffs when merging.

Thanks :-)

Sheriff Duty

• Sheriffs will watch this tree and back out bustage/regressions as necessary to keep it green.
  • Bustage is backed out right away. There's no "we'll let you fix this tree while everybody stands by".
  • The backout will be noted in the bug & if the developer is present in #developers, the sheriff will aim to also let them know of the backout via IRC. Sheriffs need only email developers about the backout outside of Bugzilla if specifically requested in the bug (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 backout more changesets to minimize the overhead/time to fix the tree. Completely innocent pushes will be relanded 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.
  • See ehsan's blogpost on how to back out multiple consecutive changesets, or mak's backout shell script or Sfink's qbackout Hg extension.
• About once a day or more, merge a green mozilla-inbound 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 mozilla-inbound. Merge any large or disruptive changes from central sooner.
  • Resolve bugs that were landed, and set the appropriate target milestone.
  • 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

mozilla-inbound is managed by an informal group of volunteer sheriffs, please be nice with them. In case of doubts you can ping any of them in #developers channel.

Join us and help out!

• edmorley (GMT / UTC)
• ehsan (EST)
• khuey (EDT)
• mak (CEST / UTC+0100)
• mbrubeck (US Pacific / UTC-0800)
• mounir (Late European TZ)
• Ms2ger (?)
• philor (PDT)
• rnewman (PDT)
• RyanVM (PDT)