Confirm
396
edits
Changes
Initial page
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|IRC account]], for communicating with developers, fellow sheriffs, and others.
* [[Sheriffing/How:To:SheriffingFromUnifiedRepos#Setting_up_the_repo|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.
* [https://www.mozilla.org/en-US/firefox/new/ A modern browser], to access [[Sheriffing/How:To:Treeherder|Treeherder]], [https://bugzilla.mozilla.org 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 [[Sheriffing/How:To|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.
= Communication =
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 [[IRC#Commonly_Used_Mozilla_IRC_Channels|here]].
= Sheriffed Repositories =
Mozilla has many dozens of different source code repositories for various projects and releases, but sheriffs only need to care about a few of them:
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-central mozilla-central], the main development repository.
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound mozilla-inbound], one of mozilla-central's integration branches where new commits initially land for testing.
* [https://treeherder.mozilla.org/#/jobs?repo=autoland autoland], another integration branch for mozilla-central.
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta mozilla-beta], one of the release stabilization branches for code that has already gone through several weeks of testing.
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-release mozilla-release], the official release branch, where Firefox code goes to become part of an official build of Firefox.
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr52 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 [https://www.mozilla.org/en-US/firefox/organizations/ 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.
= Things You'll Need =
Not all of these have to be ready on Day One, but eventually you'll need the following.
* [[IRC|IRC account]], for communicating with developers, fellow sheriffs, and others.
* [[Sheriffing/How:To:SheriffingFromUnifiedRepos#Setting_up_the_repo|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.
* [https://www.mozilla.org/en-US/firefox/new/ A modern browser], to access [[Sheriffing/How:To:Treeherder|Treeherder]], [https://bugzilla.mozilla.org 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 [[Sheriffing/How:To|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.
= Communication =
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 [[IRC#Commonly_Used_Mozilla_IRC_Channels|here]].
= Sheriffed Repositories =
Mozilla has many dozens of different source code repositories for various projects and releases, but sheriffs only need to care about a few of them:
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-central mozilla-central], the main development repository.
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound mozilla-inbound], one of mozilla-central's integration branches where new commits initially land for testing.
* [https://treeherder.mozilla.org/#/jobs?repo=autoland autoland], another integration branch for mozilla-central.
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta mozilla-beta], one of the release stabilization branches for code that has already gone through several weeks of testing.
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-release mozilla-release], the official release branch, where Firefox code goes to become part of an official build of Firefox.
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr52 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 [https://www.mozilla.org/en-US/firefox/organizations/ 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.
