canmove, Confirmed users
2,850
edits
Sheriffing/How To/Getting started as a sheriff: Difference between revisions
Jump to navigation
Jump to search
Sheriffing/How To/Getting started as a sheriff (view source)
Revision as of 16:29, 9 August 2017
, 9 August 2017→Sheriffing Tasks
ChrisCooper (talk | contribs) m (ChrisCooper moved page Sheriffing/How:To:Bootstrap to Sheriffing/How To/Getting started as a sheriff: More intuitive naming scheme) |
ChrisCooper (talk | contribs) |
||
| Line 45: | Line 45: | ||
Sheriffs do a lot of things throughout the day. | Sheriffs do a lot of things throughout the day. | ||
* Watch the sheriffed repositories via Treeherder for failures. | * Watch the sheriffed repositories via [[Sheriffing/How_To/Treeherder|Treeherder]] for failures. | ||
** Classify/Star known intermittent failures. | ** Classify/Star known intermittent failures. | ||
** File tracking bugs for newly discovered 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: | ** Resolve issues with code that has landed. This can be done with some of the following: | ||
*** Backout the bad code. | *** [[Sheriffing/How_To/Backouts|Backout]] the bad code. | ||
*** Ensure that developers land followup patches to fix issues that are discovered. | *** Ensure that developers land followup patches to fix issues that are discovered. | ||
** Monitor the repositories and tests for any issues related to infrastructure issues. | ** 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. | ** Mark repositories as being unable to accept commits from developers (also called "[[Sheriffing/Deciding_To_Close_A_Tree|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. | * [[Sheriffing/How_To/Merges|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. | ** 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. | * 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. | * Backporting approved patches (also called "[[Sheriffing/How_To/Uplifts|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. | ||