Sheriffing/How To/Getting started as a sheriff

From MozillaWiki
Jump to: navigation, search

So you want to be a Sheriff? Here's how to start.

Things You'll Need

Not all of these have to be ready on Day One, but eventually you'll need the following.

  • IRC account, for communicating with developers, fellow sheriffs, and others.
  • Clone of the Mercurial repositories, for committing changes to the repositories.
  • A properly configured mercurial setup. You can use ./mach mercurial-setup from your clone of the repository to run through a setup wizard. I recommend setting up the qbackout extension to aid in easily backing out patches.
  • LDAP account, for signing in to Treeherder and pushing commits to the source code repositories.
  • A modern browser, to access Treeherder, Bugzilla, and other Mozilla web tools.

The Sheriffs How-To

A lot of knowledge about what sheriffs do is built up by day-to-day experiences on the job. We've created a number of wiki pages documenting a lot of this information, indexed here.

Some of the more helpful (and up to date) pages:

  • Sheriffing/How:To:Treeherder - Explains some useful terminology, what each part of Treeherder's UI means/does, and how to use Treeherder to classify failures
  • Sheriffing/How:To:SheriffingFromUnifiedRepos - This is useful, though some of the referenced repositories are no longer sheriffed, and it assumes you have knowledge of a lot of Mozilla/mercurial terms.


Sheriffs hang out in the #sheriffs channel on IRC - also it's useful to be in the following Channels:

  • #developers - most of the developers are around here
  • #buildduty - our counterparts of the build system “sheriffs”
  • #releng - general Release Engineering Channel
  • #taskcluster - taskcluster team channel

A more-complete list of channels is listed here.

Sheriffed Repositories

Mozilla has dozens of different source code repositories for various projects and releases, but sheriffs only need to care about a few of them:

  • mozilla-central, the main development repository.
  • mozilla-inbound, one of mozilla-central's integration branches where new commits initially land for testing.
  • autoland, another integration branch for mozilla-central.
  • mozilla-beta, one of the release stabilization branches for code that has already gone through several weeks of testing.
  • mozilla-release, the official release branch, where Firefox code goes to become part of an official build of Firefox.
  • mozilla-esrXX, one or more branches set up to track patches for the current (and at times when the ESR releases overlap, the previous) version of Firefox ESR. (At the moment, this is mozilla-esr52.)

Once you're up to speed, it's best to leave a tab open to each of these repositories throughout your work day so you can track failures as they come in.

Sheriffing Tasks

Sheriffs do a lot of things throughout the day.

  • Watch the sheriffed repositories via Treeherder for failures.
    • Classify/Star known intermittent failures.
    • File tracking bugs for newly discovered intermittent failures.
    • Resolve issues with code that has landed. This can be done with some of the following:
      • Backout the bad code.
      • Ensure that developers land followup patches to fix issues that are discovered.
    • Monitor the repositories and tests for any issues related to infrastructure issues.
    • Mark repositories as being unable to accept commits from developers (also called "close the trees") via Treestatus, allowing you to fix issues without a bunch of new potentially-bad commits from landing in the interim.
  • Merge known-good commits from the mozilla-inbound and autoland repositories over to mozilla-central, and then back around to mozilla-inbound and autoland.
    • Once the actual merge is performed, you need to run the Bugherder tool against the merge on mozilla-central to get the information properly updated in Bugzilla. There's a link to Bugherder in the per-push menu item in Treeherder.
  • Landing approved patches that are marked as "checkin-needed" onto mozilla-inbound or autoland.
  • Backporting approved patches (also called "uplifting") from mozilla-central to one or more of the release stabilization branches (mozilla-beta, mozilla-release, mozilla-esr52, etc) to get the patch into users' hands sooner.