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), leave a note in the status 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".
  • Changes landed on top of bustage will be backed out to minimize overhead/time to fix the tree. They will be relanded by the sheriff once the bustage is cleared.
  • See ehsan's blogpost on how to back out multiple consecutive changesets, or mak's blogpost on backout shell scripts.
• About once a day or more, merge a green mozilla-inbound changeset to mozilla-central.
  • Also merge mozilla-central to mozilla-inbound. Merge sooner any large or disruptive changes from central.
  • Resolve bugs that were landed, set appropriate target milestone.

Meet the Sheriffs

mozilla-inbound is managed by an informal group of volunteer sheriffs. You can join us and help out!

• bz (EDT/UTC-0400)
• edmorley (GMT/UTC)
• ehsan (EST) (not a morning person, so might be kind of similar to PDT!)
• khuey (EDT)
• mak (CEST/UTC+0200)
• mbrubeck (US Pacific / UTC-0800)
• volkmar (Late European TZ)
• philikon (CEST/UTC+0200)
• rnewman (irregular hours for personal reasons; PDT)