{"id":486,"date":"2017-04-03T06:09:24","date_gmt":"2017-04-03T14:09:24","guid":{"rendered":"http:\/\/blog.mozilla.org\/tomcat\/?p=486"},"modified":"2017-04-03T06:09:24","modified_gmt":"2017-04-03T14:09:24","slug":"sheriffing-and-backouts","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/tomcat\/2017\/04\/03\/sheriffing-and-backouts\/","title":{"rendered":"Sheriffing@Mozilla &#8211; Sheriffing and Backouts"},"content":{"rendered":"<p>Hi,<\/p>\n<p>Keeping the code trees [1] green (meaning free of build or test failures,<br \/>\nregressions, and minimizing intermittent test failures) is the daily<br \/>\ngoal of sheriffing.<\/p>\n<p>In order to reach this goal, this means we sometimes have to back out (revert)<br \/>\nchanges made by developers. While this is a part of our job, we don&#8217;t do<br \/>\nit easily or without reason.<\/p>\n<p>Backouts happen mostly for:<br \/>\n-&gt; Bustage (i.e. Firefox no longer<br \/>\nsuccessfully builds)<br \/>\n-&gt; Test failures caused by a specific change<br \/>\n-&gt; Issues reported by the community, like startup crashes or severe<br \/>\nregressions (these backouts often lead to new nightly builds being<br \/>\ncreated as well)<br \/>\n-&gt; Performance regressions or memory leaks<br \/>\n-&gt; Issues that block merges like merge-conflicts (like for a mozilla-inbound to mozilla-central merge)<\/p>\n<p>For our primary integration repositories (where our developers land most<br \/>\ntheir changes), our workflow depends on which repository the problem is<br \/>\non.<\/p>\n<p><strong>Mozilla-Inbound<\/strong><\/p>\n<p>-&gt; Close Mozilla-Inbound if needed (preventing<br \/>\ndevelopers from landing any further changes until the problem is<br \/>\nresolved)<\/p>\n<p>-&gt; Try to notify the responsible developer so that they<br \/>\nare\u00a0 aware of the problem caused by their patch<\/p>\n<p>-&gt; If possible, we<br \/>\naccept follow-up patches to fix the problem. This allows us to fail<br \/>\nforward and avoid running extra jobs that require more CPU time and<br \/>\ntherefore increase costs.<\/p>\n<p>-&gt; If we don&#8217;t get response from the developer within a short<br \/>\ntimeframe like 5 minutes, we back out the change and comment in the<br \/>\nbug with a reason for the backout (for example, including a link to the<br \/>\nfailure log) and a needinfo to the assigne, to make sure the bug don&#8217;t get lost.<\/p>\n<p><strong>Autoland<\/strong><\/p>\n<p>-&gt; Changesets that cause problems are backed out immediately &#8211;<br \/>\nno follow-ups as described above are possible (only the sheriffs can push manually to<br \/>\nautoland)<\/p>\n<p>In any case, backouts are never meant to be personal and it&#8217;s part of<br \/>\nour job to try our best to keep our trees open for developers. We also<br \/>\ntry to provide as much information as possible in the bug for why we<br \/>\nbacked out a change.<\/p>\n<p>Of course, we also make mistakes and it could be that we backed out<br \/>\nchangesets that were innocent (like in a case where its not 100% clear<br \/>\nwhat caused the problem), but we try our best.<\/p>\n<p>If you feedback or ideas how we can make things better, let me know.<\/p>\n<p>Cheers,<br \/>\n&#8211; Tomcat<\/p>\n<p>&nbsp;<\/p>\n<p>[1] Trees: <span class=\"seoSummary\">The tree contains the source code as well as the code required to build each project on supported platforms (Linux, Windows, macOS, etc)<\/span> and tests for various areas. Sheriffs take care of Firefox Code Trees like mozilla-central, mozilla-inbound, autoland, mozilla-aurora, mozilla-beta and mozilla-esr45\/52 &#8211; our primary tool is treeherder and can be found <a href=\"http:\/\/treeherder.mozilla.org\/\">here <\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Hi, Keeping the code trees [1] green (meaning free of build or test failures, regressions, and minimizing intermittent test failures) is the daily goal of sheriffing. In order to reach this goal, this means we sometimes have to back out (revert) changes made by developers. While this is a part of our job, we don&#8217;t [&hellip;]<\/p>\n","protected":false},"author":82,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/tomcat\/wp-json\/wp\/v2\/posts\/486"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/tomcat\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/tomcat\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/tomcat\/wp-json\/wp\/v2\/users\/82"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/tomcat\/wp-json\/wp\/v2\/comments?post=486"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/tomcat\/wp-json\/wp\/v2\/posts\/486\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/tomcat\/wp-json\/wp\/v2\/media?parent=486"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/tomcat\/wp-json\/wp\/v2\/categories?post=486"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/tomcat\/wp-json\/wp\/v2\/tags?post=486"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}