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. (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 mozilla-inbound. But breaking it rarely is ok. Never missing a plane means you're spending too much time in airports; never breaking the tree means you're running too many tests before landing.)
• 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

• Leave bugs open. The sheriff will resolve them when they are merged to m-c.
• Add "[leave open]" to the whiteboard 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 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).
• 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 inbound, 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.

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 (UK / UTC or during daylight savings UTC+1)
• philor (PDT)
• mbrubeck (US Pacific / UTC-0800)
• RyanVM (EDT)
• Ms2ger (Europe)
• ehsan (EST)