https://wiki.mozilla.org/api.php?action=feedcontributions&feedformat=atom&user=TomcatMozillaWiki - User contributions [en]2026-07-08T02:20:59ZUser contributionsMediaWiki 1.39.10https://wiki.mozilla.org/index.php?title=Sheriffing/How:To:DayOne&diff=1174904Sheriffing/How:To:DayOne2017-07-03T10:47:08Z<p>Tomcat: </p>
<hr />
<div>'''Bold text'''Day one Checklist<br />
<br />
= “Software Requirements” =<br />
<br />
A unified repo - steps to set this up are here -> https://wiki.mozilla.org/Sheriffing/How:To:SheriffingFromUnifiedRepos#Setting_up_the_repo<br />
<br />
<br />
= Web - items =<br />
<br />
Most important tool is treeherder (https://treeherder.mozilla.org) here we monitor the trees and mark (we call it “star”) test and build failures. While “learning by doing” is the most effective thing, for reading we have created https://wiki.mozilla.org/Sheriffing/How:To:TBPL <br />
<br />
<br />
= The Sheriffs How-To =<br />
<br />
A lot of knowledge about Sheriffing comes from the day-to-day work and you will learn new things and maybe create your own workflow that is maybe better than any current. To share the knowledge about Sheriffing and make it a little easier for people to onboard, we have created the Sheriffs How-To here: https://wiki.mozilla.org/Sheriffing/How:To with a section about various topics. You are also invited to share/create/ new topics or maybe update “old” one with your <br />
experience.<br />
<br />
<br />
= Communication =<br />
<br />
Sheriffs hang out in the #sheriffs channel on irc - also its useful to be in the following Channels<br />
<br />
-> #developers - most of the developers are around here<br />
-> #buildduty - our counterparts of the build system “sheriffs”<br />
-> #releng - general Release Engineering Channel<br />
-> #taskcluster - taskcluster team channel</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How:To&diff=1174900Sheriffing/How:To2017-07-03T08:34:36Z<p>Tomcat: </p>
<hr />
<div>= Sheriff How-To / Knowledge Share =<br />
<br />
== B ==<br />
*[[Sheriffing/How:To:Backouts|Backouts]]<br />
*[[Sheriffing/How:To:Bisecting |Bisecting]]<br />
<br />
== C ==<br />
* [[Sheriffing/How:To:Community_Sheriffs|Community_Sheriffs and you - also current issues]]<br />
<br />
== D ==<br />
* [[Sheriffing/How:To:DayOne|Sheriffing Day - One]]<br />
* [[Sheriffing/Deciding_To_Close_A_Tree|Deciding to Close A_Tree & Actions]]<br />
<br />
== E ==<br />
* [[Sheriffing/How:To:Escalate|Escalating issues to MOC or Releng]]<br />
<br />
== H ==<br />
* [[Sheriffing/How:To:Hangs|Hangs/Timeout Failures]]<br />
<br />
== I ==<br />
* [[Sheriffing/How:To:Intermittent-bugs| How to file a Intermittent failure]]<br />
<br />
== L == <br />
* [[Sheriffing/How:To:Landing_checkin-needed_patches|Landing checkin-needed patches]]<br />
<br />
== M == <br />
* [[Sheriffing/How:To:Merges|Merges]]<br />
* [[Sheriffing/How:To:Merge_Conflicts|Merge Conflicts]]<br />
<br />
== R ==<br />
* [[Sheriffing/How:To:Restarts|Retrigger (Restart)]]<br />
* [[Sheriffing/How:To:Retrigger_PGO_Builds|Retrigger PGO/Nightlies]] <br />
<br />
== S ==<br />
* [[Sheriffing/How:To:Sheriffs-Schedule| Sheriffing Schedule]]<br />
<br />
== T == <br />
* [[Sheriffing/How:To:TBPL|Treeherder]]<br />
* [[Sheriffing/How:To:Trees|Trees]]<br />
<br />
== U ==<br />
* [[Sheriffing/How:To:Uplifts|Uplifts]]<br />
* [[Sheriffing/How:To:SheriffingFromUnifiedRepos|SheriffingFromUnifiedRepos]]</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Deciding_To_Close_A_Tree&diff=1174899Sheriffing/Deciding To Close A Tree2017-07-03T08:33:15Z<p>Tomcat: </p>
<hr />
<div>== Deciding to close a tree ==<br />
<br />
Many objective and subjective criteria are part of deciding to close a tree. Tree closure means that developers are prevented from pushing or merging code to a codebase. Later, sheriffs will reopen the trees when the problem appears to be resolved.<br />
<br />
Some of the criteria used include: <br />
* Broken build on an integration or main tree (e.g. mozilla-inbound, mozilla-central, autoland)<br />
* Excessive backlog for builds or tests in any platform<br />
* Infrastructure or systems failures that affect a significant number of tests or builds (e.g. AWS, data center, networking issues)<br />
* Mass "bustage" that could hide other test failures (this is when code lands and causes multiple tests to fail across multiple chunks of tests or suites of tests, making it harder to catch further failures if something else lands *during* the period in which these tests are failing from the original code landing)<br />
* Infra failure that affects our ability to see what's happening (e.g. treeherder being down or not ingesting jobs or the data it consumes not being updated, or treestatus being broken so we're closed by default)<br />
<br />
== Actions to take ==<br />
<br />
Mostly this Tree-Closures are due failing Code (like Build Bustages, Test failures) and are this Tree Closures are normally fixed very fast. However we might have cases where we have longer Tree-Closures due to Infra Related Problems that are UN-planned and need deeper investigations by Teams like IT,Releng, Taskcluster etc<br />
<br />
For this cases we might need notifications to Developers to :<br />
<br />
<br />
* Avoid frustrations when people want to push to try and notice its not possible<br />
* Pending/Running Testruns (especially try) fails to whatever unrelated reasons and cause a Developer to spend time on issues that are not caused by her/his changes<br />
* Reduce hammering on Sheriffs why a tree is closed and whats the eta etc<br />
<br />
=== Steps to-do from the onduty Sheriff ===<br />
<br />
1.) make clear that there is a outage and who is the current Sheriff with changing the topic of the #developers channel on IRC. Please add also the tracking bug and a possible eta time into the topic of #developers.<br />
<br />
example:<br />
Onduty-Sheriff: Tomcat - All Tree Closure - Database issue Bug 1234567 - no eta yet<br />
<br />
2. Also post to #treestatus about the tree closure <br />
<br />
3.) If the tree closures is expect to be a longer problem -> Post a short mail to the mozilla.dev.platform and dev-fxos <dev-fxos@lists.mozilla.org> newsgroup like https://groups.google.com/forum/#!topic/mozilla.dev.platform/Kzd1es4KiYA - also like here the next sheriff could if the issue is fixed sent a all clear information.</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Uplifts&diff=1174700Sheriffing/How To/Uplifts2017-06-29T06:48:43Z<p>Tomcat: no more aurora and gaia</p>
<hr />
<div>Standard practice is that bug fixes that affect the release branches must first land on trunk/master. Unless there is a branch-specific patch attached to the bug, the patch that landed must then be transplanted to the appropriate branches. This page documents the procedure for performing those uplifts..<br />
<br />
= Prerequisites =<br />
To perform uplifts with Mercurial, either the native [http://www.selenic.com/hg/help/graft graft] command or the [http://mercurial.selenic.com/wiki/TransplantExtension transplant] extension needs to be enabled, depending on how the different branches are cloned. Git has native [http://www.git-scm.com/docs/git-cherry-pick cherry-pick] functionality that can be used for all Gaia uplifts (or Gecko if using the Git mirror).<br />
<br />
== Gecko Uplifts ==<br />
=== Using Separate Repositories ===<br />
By default, the different Gecko branches live in different repositories. With multiple repos, the transplant extension is the preferred method. Creating an [http://www.selenic.com/mercurial/hgrc.5.html#alias alias] simplifies the process for transplanting a given revision <b>(or revset)</b>.<br />
# Transplant a cset from the specified branch to the current branch and edit the commit message.<br />
# *** This assumes that local clones are named mozilla-XXX (aurora, beta, etc). ***<br />
# Usage: hg uplift &#60;source&#62; &#60;rev&#62;<br />
# Example: hg uplift aurora abc123abc123<br />
uplift = transplant -e -s ../mozilla-$1 $2<br />
<br />
Optionally, an mq-based alias can also be created, which exports a specified revision from the current clone and imports it into another.<br />
# Export a cset from the current branch to the specified branch, add it to the queue, attempt to apply it, and edit the commit message.<br />
# *** This assumes that local clones are named mozilla-XXX (aurora, beta, etc). ***<br />
# Usage: hg uplift-mq &#60;branch&#62; &#60;bug#&#62; &#60;rev&#62;<br />
# Example: hg uplift-mq aurora 123456 abc123abc123<br />
uplift-mq = !hg export -r $3 > ../mozilla-$1/.hg/patches/$2 && cd ../mozilla-$1 && hg qimport -e -P $2 && hg qref -e<br />
<br />
<b>NOTE: The above aliases work in opposite directions!</b><br />
<br />
=== Using A Unified Repository ===<br />
When using the [http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html Firefoxtree] extension, all the Gecko releases live in the same repository. The native graft function can be used.<br />
hg graft -er &#60;rev&#62;<br />
<br />
= Uplift Procedure =<br />
* Unless specifically cleared by Release Management, patches should land on mozilla-central prior to being uplifted elsewhere.<br />
* Patches should be uplifted from the most-recent version to the oldest (i.e. Aurora -> Beta -> etc or v2.2 -> v2.1 -> etc). This will help minimize rebasing pain.<br />
* To avoid conflicts, patches should be transplanted from oldest to newest. The search queries below default to sorting in the order the bugs were resolved.<br />
** Until bug 1154728 is resolved, note that Bugherder marks bugs in the *opposite* order of which they landed!<br />
* If there is a branch-specific patch attached to the bug, use that. Otherwise, transplant it using the methods shown in the section above.<br />
* Add a=<whoever approved> to the commit message.<br />
* After pushing, mark the bugs and set the appropriate status flags. The Bugherder tool available from the dropdown on the right side of each push on Treeherder can automate this process.<br />
<br />
= Bug Queries =<br />
The [https://bugzilla.mozilla.org/page.cgi?id=release_tracking_report.html Release Tracking Report] has some useful bug queries. However, it has limitations in that it only sees bugs that have a status of "affected", "fixed", or "verified" set. As a result, it will miss approved bugs if no status is set ("---") and will show bugs as still needing uplift if their status is an unexpected value (like "disabled"). As a result, a combination of this report and the queries below is recommended to avoid missing bugs.<br />
<br />
== ESR ==<br />
The ESR intermittent queries are *very* useful for looking at recently-fixed intermittent failure bugs and ensuring that status flags are set for all applicable releases. The [https://wiki.mozilla.org/RapidRelease/Calendar Release Calendar] can help determine in which release an intermittent first appeared (in addition to looking at Treeherderbot comments in the bug).<br />
<br />
<b>ESR52</b><br />
<br />
[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;field0-0-0=flagtypes.name;type0-0-0=equals;value0-0-0=approval-mozilla-esr52%2B;field0-1-0=cf_status_firefox_esr52;type0-1-0=nowordssubstr;value0-1-0=fixed%20verified%20wontfix%20unaffected%20disabled All esr52 approvals not yet uplifted]<br />
<br />
= Best Practice =<br />
<br />
* Use a unified tree https://wiki.mozilla.org/Sheriffing/How:To:SheriffingFromUnifiedRepos can help you with that<br />
* Use the queries from release_tracking_report to find Bugs to uplift as example<br />
as example "show where approval-mozilla-aurora was changed to approval + between - use custom dates <br />
set the current status of the current aurora version as unfixed like status mozilla-51 not fixed<br />
* Use the Resulting Bugs to uplift <br />
<br />
* If you have patches like a rebased - aurora patch where a straight uplift from mozilla-central to like aurora don't work see https://wiki.mozilla.org/Sheriffing/How:To:SheriffingFromUnifiedRepos#Single_repository_and_single_set_of_patches<br />
<br />
* As example for a beta uplift from mozilla-central<br />
Pull and update to prepare for the uplifts:<br />
hg pull central<br />
hg pull beta<br />
hg up beta<br />
<br />
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:<br />
hg graft --edit -r <revision><br />
<br />
Repeat the previous step as needed for all uplifts as needed. Verify the outgoing changes and push:<br />
hg out -r . beta<br />
hg push -r . beta</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How:To:Quick-Reference&diff=1174594Sheriffing/How:To:Quick-Reference2017-06-27T13:44:55Z<p>Tomcat: Created page with "== Sheriffs Quick Reference == = Treeherder Shortcut Keys = r = retrigger (restart) n = next unstared failure u = show only unstared failures = Backout = Copy backout..."</p>
<hr />
<div>== Sheriffs Quick Reference ==<br />
<br />
= Treeherder Shortcut Keys =<br />
<br />
r = retrigger (restart)<br />
n = next unstared failure <br />
u = show only unstared failures<br />
<br />
= Backout = <br />
<br />
Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason><br />
hg backout -r <revision><br />
<br />
This should open up your editor with a completely empty commit message. Type in the backout message like "Backout revision <revision> (bug <number>) for <reason>" (possibly with "CLOSED TREE" in there to get around a closure hook).<br />
<br />
= Checkin (like checkin-needed) =<br />
<br />
Update mozilla-inbound and prepare for the patches:<br />
<br />
hg pull inbound<br />
hg up inbound<br />
hg bookmark m-i-checkins<br />
<br />
Import the patches:<br />
<br />
hg import https://link.to/correct/checkin-needed.patch<br />
Repeat ^ as needed for all mozilla-inbound checkin-needed patches<br />
<br />
Verify your outgoing changes:<br />
<br />
hg out -r . inbound<br />
<br />
If you haven't lost a push race:<br />
<br />
hg push -r . inbound<br />
<br />
Delete your no longer needed bookmark: <br />
<br />
hg bookmark -d m-i-checkins<br />
<br />
<br />
= Lost a Push Race (like someone pushed to the repo while you also prepare a backout/checkin =<br />
<br />
If you lost a push race:<br />
<br />
hg pull inbound<br />
hg rebase -d mozilla-inbound<br />
hg push -r . mozilla-inbound</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Uplift-Sim&diff=1174417Sheriffing/Uplift-Sim2017-06-22T14:12:28Z<p>Tomcat: </p>
<hr />
<div>In order to prevent long Tree-Closures after Release Merge Day, Sheriffs are now doing regular simulations of Code Merges from like Trunk -> Aurora, Aurora -> Beta and Trunk -> Beta<br />
<br />
The steps how to do this Simulations are documented here :<br />
<br />
> Have a m-c unified repo somehere<br />
-> hg import the patches that you want like Early Beta/Late Beta<br />
-> for commit on the last changeset use the try synatx that philor suggested<br />
for as beta pushes<br />
try: -b do -p all -u all[-10.6,-Windows XP] -t none --no-retry <br />
<br />
for as dev-edtion :<br />
try: -b o -p linux-devedition-nightly,linux64-devedition-nightly,macosx64,win32,win64 -u all[-10.6,-Windows XP] -t all[-10.6,-Windows XP]<br />
<br />
-> Push to try (if you are not familiar with the try server [[ReleaseEngineering/TryServer|here]] is a good link to read)<br />
<br />
The patches that contain the configurations changes are in [https://bugzilla.mozilla.org/show_bug.cgi?id=1280663 Bug 1280663]<br />
<br />
Using the the first 2 patches of that bug gets you late beta - when you include the 3rd patch -> Early Beta<br />
<br />
And the last patch from the bug gets you Dev Edition.</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How:To&diff=1173465Sheriffing/How:To2017-06-14T12:21:26Z<p>Tomcat: </p>
<hr />
<div>= Sheriff How-To / Knowledge Share =<br />
<br />
== B ==<br />
*[[Sheriffing/How:To:Backouts|Backouts]]<br />
*[[Sheriffing/How:To:Bisecting |Bisecting]]<br />
<br />
== C ==<br />
* [[Sheriffing/How:To:Community_Sheriffs|Community_Sheriffs and you - also current issues]]<br />
<br />
== D ==<br />
* [[Sheriffing/How:To:DayOne|Sheriffing Day - One]]<br />
<br />
== E ==<br />
* [[Sheriffing/How:To:Escalate|Escalating issues to MOC or Releng]]<br />
<br />
== H ==<br />
* [[Sheriffing/How:To:Hangs|Hangs/Timeout Failures]]<br />
<br />
== I ==<br />
* [[Sheriffing/How:To:Intermittent-bugs| How to file a Intermittent failure]]<br />
<br />
== L == <br />
* [[Sheriffing/How:To:Landing_checkin-needed_patches|Landing checkin-needed patches]]<br />
<br />
== M == <br />
* [[Sheriffing/How:To:Merges|Merges]]<br />
* [[Sheriffing/How:To:Merge_Conflicts|Merge Conflicts]]<br />
<br />
== R ==<br />
* [[Sheriffing/How:To:Restarts|Retrigger (Restart)]]<br />
* [[Sheriffing/How:To:Retrigger_PGO_Builds|Retrigger PGO/Nightlies]] <br />
<br />
== S ==<br />
* [[Sheriffing/How:To:Sheriffs-Schedule| Sheriffing Schedule]]<br />
<br />
== T == <br />
* [[Sheriffing/How:To:TBPL|Treeherder]]<br />
* [[Sheriffing/How:To:Trees|Trees]]<br />
<br />
== U ==<br />
* [[Sheriffing/How:To:Uplifts|Uplifts]]<br />
* [[Sheriffing/How:To:SheriffingFromUnifiedRepos|SheriffingFromUnifiedRepos]]</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Intermittent_bugs&diff=1173464Sheriffing/How To/Intermittent bugs2017-06-14T12:19:06Z<p>Tomcat: </p>
<hr />
<div>= How to file a Bug for a Test Failure aka Intermittent Bug =<br />
<br />
When you discover during your work on tree herder test failures who occurred only once (intermittent) we need a file a bug for this since the test might be need a change to make that test more stable.<br />
<br />
In a lot of cases the test failure happened before and someone else or maybe yourself filed a bug for that failure days or weeks ago. In such cases treeherder suggest the Bug Number and title under the failure like<br />
<br />
[[File:Treeherder suggestion.png|Treeherder suggestions]]<br />
<br />
Filing a Bug so that its getting picked up by treeherder as in the screenshot before is very easy. <br />
<br />
Bascially 2 requirements need to be included in the bug that this bug can automatically picked up by treeheder:<br />
<br />
1. In the summary: '''Intermittent''' test_file test failure<br />
2. In the Keyword field choose the keyword: '''intermittent-failure'''<br />
<br />
== Best Pratice ==<br />
<br />
Lets imagine you have a test failure like TEST-UNEXPECTED-TIMEOUT | /navigation-timing/test_timing_xserver_redirect.html | expected OK in Treeherder and there is no bug filed so far for this failure. <br />
<br />
-> Open the Treeherder Log<br />
1. Login into Bugzilla in a different tab<br />
2. Find the Product/Component where you need to file this bug (note: mxr and hg.mozilla.org can be very helpful if you are in doubt)<br />
3. In this example the Bug belong to Core:Document Navigation<br />
4. Copy the failure text from the logwindow into the bug <br />
5. In the Summary: file the Bug as title: Intermittent navigation-timing/test_timing_xserver_redirect.html | expected OK<br />
6. In the keyword field choose intermittent-failure<br />
7. submit the bug<br />
<br />
in a perfect world the bug would like https://bugzilla.mozilla.org/show_bug.cgi?id=1172135 :) <br />
<br />
Treeherder syncs with bugzilla several times a day and so when this this is done from the next failure on your bug will be suggested for this failure!<br />
<br />
Also if you want you can add %bugfiler to the treeherder url like https://treeherder.mozilla.org/#/jobs?repo=autoland&bugfiler - this activates bugfiler (the little bug icon beside a failure) that does most of the manual steps from the upper section</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How:To&diff=1173463Sheriffing/How:To2017-06-14T12:16:49Z<p>Tomcat: </p>
<hr />
<div>= Sheriff How-To / Knowledge Share =<br />
<br />
== B ==<br />
*[[Sheriffing/How:To:Backouts|Backouts]]<br />
*[[Sheriffing/How:To:Bisecting |Bisecting]]<br />
<br />
== C ==<br />
* [[Sheriffing/How:To:Community_Sheriffs|Community_Sheriffs and you - also current issues]]<br />
<br />
== D ==<br />
* [[Sheriffing/How:To:DayOne|Sheriffing Day - One]]<br />
<br />
== E ==<br />
* [[Sheriffing/How:To:Escalate|Escalating issues to MOC or Releng]]<br />
<br />
== G ==<br />
<br />
<br />
== H ==<br />
* [[Sheriffing/How:To:Hangs|Hangs/Timeout Failures]]<br />
<br />
== L == <br />
* [[Sheriffing/How:To:Landing_checkin-needed_patches|Landing checkin-needed patches]]<br />
<br />
== M == <br />
* [[Sheriffing/How:To:Merges|Merges]]<br />
* [[Sheriffing/How:To:Merge_Conflicts|Merge Conflicts]]<br />
<br />
== R ==<br />
* [[Sheriffing/How:To:Restarts|Retrigger (Restart)]]<br />
* [[Sheriffing/How:To:Retrigger_PGO_Builds|Retrigger PGO/Nightlies]] <br />
<br />
== S ==<br />
* [[Sheriffing/How:To:Sheriffs-Schedule| Sheriffing Schedule]]<br />
<br />
== T == <br />
* [[Sheriffing/How:To:TBPL|Treeherder]]<br />
* [[Sheriffing/How:To:Trees|Trees]]<br />
<br />
== U ==<br />
* [[Sheriffing/How:To:Uplifts|Uplifts]]<br />
* [[Sheriffing/How:To:SheriffingFromUnifiedRepos|SheriffingFromUnifiedRepos]]</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How:To:TBPL&diff=1173461Sheriffing/How:To:TBPL2017-06-14T12:15:03Z<p>Tomcat: </p>
<hr />
<div>Treeherder<br />
<br />
= What does staring do? Er, what does starring do? Does it restart that particular build? =<br />
<br />
Starring does three things:<br />
<br />
1) adds a comment to the bugzilla bug (if it was a bug suggestion shown by Treeherder, this doesn't happen for manually typed things)<br />
<br />
2) Submits the failure to OrangeFactor (think crashstats, but for intermittent failures)<br />
<br />
3) Stores the comment in Treeherders's database, so everyone viewing that tree/push can see that the failure has been starred (ie annotated with a comment and the asterisk next to the job), so they know it's not real breakage<br />
<br />
Every 2 mins the TBPL UI refreshes and will pull down new jobs and also new annotations that other sheriffs might have<br />
added on their UI <br />
<br />
Treeherder also displays a "unstarred failures" count in the top right of the UI (also the tab title)<br />
pressing "u" will toggle into "only display unstarred failures" mode, which is handy<br />
<br />
= Red, Green, whatever :) =<br />
<br />
Treeherder displays statues and test results in different colors like:<br />
<br />
lightgray = pending<br />
<br />
gray = running<br />
<br />
green = success<br />
<br />
orange = tests failed<br />
<br />
purple = infrastructure exception<br />
<br />
red = build error<br />
<br />
blue = build has been restarted<br />
<br />
pink =build was cancelled<br />
<br />
black = unknown error<br />
<br />
= How are things starred?=<br />
<br />
If you click on a non-green job symbol on Treeherder the box will appear bottom right of the ui, with the summary of the failure.<br />
<br />
It will will show log lines that match a set of hardcoded regexp.<br />
<br />
If bugzilla searches for keywords from those lines matched any bugs (bugs with the keyword "intermittent-failure") then they will be displayed in the blue box to select a bug, you click the star next to that row.<br />
<br />
= Useful Shortcuts =<br />
<br />
Treeherder supports a series of useful Shortcuts. As Sheriffs these shortcuts are super helpful:<br />
<br />
u = Toggle showing only unstarred failures<br />
n = Highlight next unstarred failure<br />
p = Highlight previous unstarred failure<br />
<br />
= More Technical Source =<br />
<br />
can be found here [[Auto-tools/Projects/Treeherder]]</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How:To&diff=1173459Sheriffing/How:To2017-06-14T12:13:49Z<p>Tomcat: </p>
<hr />
<div>= Sheriff How-To / Knowledge Share =<br />
<br />
== B ==<br />
*[[Sheriffing/How:To:Backouts|Backouts]]<br />
*[[Sheriffing/How:To:Bisecting |Bisecting]]<br />
<br />
== C ==<br />
* [[Sheriffing/How:To:Community_Sheriffs|Community_Sheriffs and you - also current issues]]<br />
<br />
== D ==<br />
* [[Sheriffing/How:To:DayOne|Sheriffing Day - One]]<br />
<br />
== E ==<br />
* [[Sheriffing/How:To:Escalate|Escalating issues to MOC or Releng]]<br />
<br />
== G ==<br />
<br />
<br />
== H ==<br />
* [[Sheriffing/How:To:Hangs|Hangs/Timeout Failures]]<br />
<br />
== L == <br />
* [[Sheriffing/How:To:Landing_checkin-needed_patches|Landing checkin-needed patches]]<br />
<br />
== M == <br />
* [[Sheriffing/How:To:Merges|Merges]]<br />
* [[Sheriffing/How:To:Merge_Conflicts|Merge Conflicts]]<br />
<br />
== R ==<br />
* [[Sheriffing/How:To:Restarts|Retrigger (Restart)]]<br />
* [[Sheriffing/How:To:Retrigger_PGO_Builds|Retrigger PGO/Nightlies]] <br />
<br />
== S ==<br />
* [[Sheriffing/How:To:Sheriffs-Schedule| Sheriffing Schedule]]<br />
<br />
== T == <br />
* [[Sheriffing/How:To:TBPL|TBPL]]<br />
* [[Sheriffing/How:To:Trees|Trees]]<br />
<br />
== U ==<br />
* [[Sheriffing/How:To:Uplifts|Uplifts]]<br />
* [[Sheriffing/How:To:SheriffingFromUnifiedRepos|SheriffingFromUnifiedRepos]]</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Retrigger_Jobs&diff=1173458Sheriffing/How To/Retrigger Jobs2017-06-14T12:13:19Z<p>Tomcat: </p>
<hr />
<div>Retrigger of Builds/Tests<br />
<br />
Sometimes Builds/Tests need to restart. There is a automated way for some condiditons, see below - and there is a manual way <br />
<br />
<br />
= The Manual Way =<br />
<br />
Sometimes we need to restart a Build/tests like for Bad Revisions etc, same for tests when we want to check out if a failure is intermittent. To complete this Task you need to select a test result in treeherder and click on it. You will see a box in the left bottom corner with information like the Testname Name: (as example Windows XP 32-bit fx-team opt test mochitest-5). <br />
<br />
To retrigger a job/test click on the circle beside the Testname in that box and the test will be retriggered. Same also if you just press "r" when you are logged-in</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Hangs&diff=1173457Sheriffing/How To/Hangs2017-06-14T12:10:14Z<p>Tomcat: </p>
<hr />
<div>Hang/Timeout Test Failures need special attention<br />
<br />
When a test hangs, and "application timed out after 330 seconds with no<br />
output," we kill the process just in case something interesting was<br />
happening, and put a "crash" stack in the log.<br />
<br />
There's almost never anything significant at the top of the stack, even<br />
when we were actually up to something, the (rare) significance is more<br />
likely to be buried in some other thread. But most of the time, we're<br />
just sitting spinning the event loop, waiting for something to happen<br />
that isn't ever going to happen, and the "crash" signature is<br />
CrashingThread(void *), or libSystem.B.dylib + 0xd7a, or linux-gate.so +<br />
0x424.<br />
<br />
Those signatures mean absolutely nothing beyond what you're already<br />
saying in the summary, application timed out after 330 seconds with no<br />
output, but thanks to the power of (treeherder's bug) suggestion, if you look<br />
at hang bugs, you'll see that when we get in a hurry, we happily star<br />
things like "test_HTMLElement58.html | application timed out after 330<br />
seconds with no output" as "Windows mochitest-1,2,3 hangs on Shutdown |<br />
application timed out after 330 seconds with no output".<br />
<br />
Please don't put any of those three things in bug summaries, please<br />
remove them when you see them, and please don't star new unfiled hangs<br />
as something utterly different in a different test. The only time we<br />
need them in the summary is when we don't have a test name, which should<br />
only be the case for Shutdown, where we just need to gather up the<br />
strength to not to call an unfiled test timeout a shutdown timeout, even<br />
if treeherder suggests it.</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How:To&diff=1173456Sheriffing/How:To2017-06-14T12:09:16Z<p>Tomcat: </p>
<hr />
<div>= Sheriff How-To / Knowledge Share =<br />
<br />
== B ==<br />
*[[Sheriffing/How:To:Backouts|Backouts]]<br />
*[[Sheriffing/How:To:Bisecting |Bisecting]]<br />
<br />
== C ==<br />
* [[Sheriffing/How:To:Community_Sheriffs|Community_Sheriffs and you - also current issues]]<br />
<br />
== D ==<br />
* [[Sheriffing/How:To:DayOne|Sheriffing Day - One]]<br />
<br />
== E ==<br />
* [[Sheriffing/How:To:Escalate|Escalating issues to MOC or Releng]]<br />
<br />
== G ==<br />
<br />
<br />
== H ==<br />
* [[Sheriffing/How:To:Hangs|Hangs/Timeout Failures]]<br />
<br />
== L == <br />
* [[Sheriffing/How:To:Landing_checkin-needed_patches|Landing checkin-needed patches]]<br />
<br />
== M == <br />
* [[Sheriffing/How:To:Merges|Merges]]<br />
* [[Sheriffing/How:To:Merge_Conflicts|Merge Conflicts]]<br />
<br />
== R ==<br />
* [[Sheriffing/How:To:Restarts|Restarts]]<br />
* [[Sheriffing/How:To:Retrigger_PGO_Builds|Retrigger PGO/Nightlies]] <br />
<br />
== S ==<br />
* [[Sheriffing/How:To:Sheriffs-Schedule| Sheriffing Schedule]]<br />
<br />
== T == <br />
* [[Sheriffing/How:To:TBPL|TBPL]]<br />
* [[Sheriffing/How:To:Trees|Trees]]<br />
<br />
== U ==<br />
* [[Sheriffing/How:To:Uplifts|Uplifts]]<br />
* [[Sheriffing/How:To:SheriffingFromUnifiedRepos|SheriffingFromUnifiedRepos]]</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How:To&diff=1173455Sheriffing/How:To2017-06-14T12:08:44Z<p>Tomcat: </p>
<hr />
<div>= Sheriff How-To / Knowledge Share =<br />
<br />
== B ==<br />
*[[Sheriffing/How:To:Backouts|Backouts]]<br />
*[[Sheriffing/How:To:Bisecting |Bisecting]]<br />
<br />
== C ==<br />
* [[Sheriffing/How:To:Community_Sheriffs|Community_Sheriffs and you - also current issues]]<br />
<br />
== D ==<br />
* [[Sheriffing/How:To:DayOne|Sheriffing Day - One]]<br />
<br />
== E ==<br />
* [[Sheriffing/How:To:Escalate|Escalating issues to MOC or Releng]]<br />
<br />
== G ==<br />
* [[Sheriffing/How:To:gaia.json|gaia.json and merge conflicts with this file]] <br />
<br />
== H ==<br />
* [[Sheriffing/How:To:Hangs|Hangs/Timeout Failures]]<br />
<br />
== L == <br />
* [[Sheriffing/How:To:Landing_checkin-needed_patches|Landing checkin-needed patches]]<br />
<br />
== M == <br />
* [[Sheriffing/How:To:Merges|Merges]]<br />
* [[Sheriffing/How:To:Merge_Conflicts|Merge Conflicts]]<br />
<br />
== R ==<br />
* [[Sheriffing/How:To:Restarts|Restarts]]<br />
* [[Sheriffing/How:To:Retrigger_PGO_Builds|Retrigger PGO/Nightlies]] <br />
<br />
== S ==<br />
* [[Sheriffing/How:To:Sheriffs-Schedule| Sheriffing Schedule]]<br />
<br />
== T == <br />
* [[Sheriffing/How:To:TBPL|TBPL]]<br />
* [[Sheriffing/How:To:Trees|Trees]]<br />
<br />
== U ==<br />
* [[Sheriffing/How:To:Uplifts|Uplifts]]<br />
* [[Sheriffing/How:To:SheriffingFromUnifiedRepos|SheriffingFromUnifiedRepos]]</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Community_Sheriffs&diff=1173454Sheriffing/How To/Community Sheriffs2017-06-14T12:07:02Z<p>Tomcat: </p>
<hr />
<div>= Join us as Community Sheriff =<br />
<br />
As any other part of Mozilla also we depend on Community and always happy to find new Community Sheriffs.<br />
<br />
Part of the Community Sheriffs is:<br />
<br />
* Staring of unstared failures in TBPL<br />
* Merges from the Mozilla Trees <br />
* Communication Role, like available in IRC for Questions from other Developers about the Tree and checkins<br />
<br />
If you want to get started looking at the TBPL Documentation is the first step and let us know when we can help you.<br />
<br />
You can contact us via mail sheriffs at mozilla dot org or on IRC in #developers or #sheriffs<br />
<br />
= Who are the Sheriffs =<br />
<br />
Sheriffs:<br />
<br />
* Phil Ringnalda [:philor] - UTC-8<br />
* Carsten Book [:Tomcat] - UTC+1<br />
* Wes Kocher [:KWierso] - UTC-8</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Community_Sheriffs&diff=1173453Sheriffing/How To/Community Sheriffs2017-06-14T12:05:52Z<p>Tomcat: </p>
<hr />
<div>= Join us as Community Sheriff =<br />
<br />
As any other part of Mozilla also we depend on Community and always happy to find new Community Sheriffs.<br />
<br />
Part of the Community Sheriffs is:<br />
<br />
* Staring of unstared failures in TBPL<br />
* Merges from the Mozilla Trees <br />
* Communication Role, like available in IRC for Questions from other Developers about the Tree and checkins<br />
<br />
If you want to get started looking at the TBPL Documentation is the first step and let us know when we can help you.<br />
<br />
You can contact us via mail sheriffs at mozilla dot org or on IRC in #developers or #ateam<br />
<br />
= Who are the Sheriffs =<br />
<br />
Sheriffs:<br />
<br />
* Phil Ringnalda [:philor] - UTC-8<br />
* Carsten Book [:Tomcat] - UTC+1<br />
* Wes Kocher [:KWierso] - UTC-8</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Backouts&diff=1173452Sheriffing/How To/Backouts2017-06-14T12:04:57Z<p>Tomcat: </p>
<hr />
<div>When a patch is landed that causes build or test failures, it must be backed out to restore the tree to a passing state again. This page documents the procedure for performing backouts both for Gecko changes and Gaia.<br />
<br />
= New recommended way of backouts =<br />
<br />
* With unified repos backouts are now more easily - please follow [[Sheriffing/How:To:SheriffingFromUnifiedRepos|Unified Repos Backup]]<br />
<br />
<br />
= Gecko Backouts =<br />
== Prerequisites ==<br />
* Install the qbackout extension from https://hg.mozilla.org/hgcustom/version-control-tools/file/default/hgext/qbackout<br />
* Instructions: https://hg.mozilla.org/hgcustom/version-control-tools/file/default/hgext/qbackout/README<br />
<br />
== Usage ==<br />
=== Backout of a single changeset===<br />
hg qbackout -e -r 123456789abc<br />
Where -r is the specific revision to be backed out. The -e option opens an editor to edit the commit message prior to committing. This is useful for adding DONTBUILD, CLOSED TREE, etc before pushing.<br />
<br />
=== Backout of multiple consecutive changesets ===<br />
hg qbackout -e -s -r 123456789abc:cba987654321<br />
Where the -r is now specifying a range of commits (from 123456789abc to cba987654321). The -s option commits the backouts as a single commit. Otherwise, each changeset in the range will be backed out as separate commits.<br />
<br />
=== Backout of multiple non-consecutive changesets ===<br />
hg qbackout -e -s -r 123456789abc+cba987654321<br />
Useful when there are commits in between the ones that need backing out.<br />
<br />
=== Backout of a combination of consecutive and non-consecutive changesets ===<br />
hg qbackout -e -s -r 123456789abc:cba987654321+xyz456789123<br />
Useful when a follow-up patch needs backing out in addition to the main one (i.e. someone had a follow-up bustage fix push) or an additional commit conflicts with the backout and needs backing out as well.<br />
<br />
== Pushing ==<br />
hg qfinish -a<br />
hg push<br />
Finalizes the patch for pushing to the remote repo.<br />
<br />
=== What Ifs ===<br />
* If the remote repo has additional changesets (i.e. a push race), hg pull --rebase will pull the new changesets and rebase the local changes on top of them.<br />
** This requires the [http://mercurial.selenic.com/wiki/RebaseExtension rebase] extension to be enabled in .hgrc<br />
* If the commit message needs to be modifying after qfinish (i.e. forgotten CLOSED TREE), hg commit --amend will open the backout in an editor for modification.<br />
<br />
<br />
= Best Practices and Communication =<br />
<br />
Based on Feedback from the Sheriff Survey, when you have to do a backout some best practice<br />
<br />
* Ping the Developer in IRC if possible and when the developer is around, this gives the developer a chance to fix the problem and so avoid a backout. Some of the sheriffs use a 5 minute rule for the waiting of a response of the developer<br />
* Set Need-info! This is very important! Developers get a lot of bugmail and so a backout comment can be missed - please make sure that you set a need-info to the developer in the bug when doing a backout<br />
* Make sure that the failures that lead to the backout are stared in treeherder - this helps a lot also the following sheriffs.</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How:To&diff=1173451Sheriffing/How:To2017-06-14T12:00:08Z<p>Tomcat: </p>
<hr />
<div>= Sheriff How-To / Knowledge Share =<br />
<br />
== B ==<br />
*[[Sheriffing/How:To:Backouts|Backouts]]<br />
*[[Sheriffing/How:To:Bisecting |Bisecting]]<br />
<br />
== C ==<br />
* [[Sheriffing/How:To:Community_Sheriffs|Community_Sheriffs and you - also current issues]]<br />
<br />
== D ==<br />
* [[Sheriffing/How:To:DayOne|Sheriffing Day - One<br />
<br />
== E ==<br />
* [[Sheriffing/How:To:Escalate|Escalating issues to MOC or Releng]]<br />
<br />
== G ==<br />
* [[Sheriffing/How:To:gaia.json|gaia.json and merge conflicts with this file]] <br />
<br />
== H ==<br />
* [[Sheriffing/How:To:Hangs|Hangs/Timeout Failures]]<br />
<br />
== L == <br />
* [[Sheriffing/How:To:Landing_checkin-needed_patches|Landing checkin-needed patches]]<br />
<br />
== M == <br />
* [[Sheriffing/How:To:Merges|Merges]]<br />
* [[Sheriffing/How:To:Merge_Conflicts|Merge Conflicts]]<br />
<br />
== R ==<br />
* [[Sheriffing/How:To:Restarts|Restarts]]<br />
* [[Sheriffing/How:To:Retrigger_PGO_Builds|Retrigger PGO/Nightlies]] <br />
<br />
== S ==<br />
* [[Sheriffing/How:To:Sheriffs-Schedule| Sheriffing Schedule]]<br />
<br />
== T == <br />
* [[Sheriffing/How:To:TBPL|TBPL]]<br />
* [[Sheriffing/How:To:Trees|Trees]]<br />
<br />
== U ==<br />
* [[Sheriffing/How:To:Uplifts|Uplifts]]<br />
* [[Sheriffing/How:To:SheriffingFromUnifiedRepos|SheriffingFromUnifiedRepos]]</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How:To:DayOne&diff=1172528Sheriffing/How:To:DayOne2017-06-02T13:59:33Z<p>Tomcat: </p>
<hr />
<div>'''Bold text'''Day one Checklist<br />
<br />
= “Software Requirements” =<br />
<br />
Up to do Mercurial Installation either from https://www.mercurial-scm.org/downloads or the download source of your choice <br />
Make sure you read https://developer.mozilla.org/de/docs/Installing_Mercurial<br />
A clone of the mozilla-central, mozilla-inbound, autoland code-tree (https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Source_Code/Mercurial can be helpful) <br />
or/and <br />
A unified repo - steps to set this up are here -> https://wiki.mozilla.org/Sheriffing/How:To:SheriffingFromUnifiedRepos#Setting_up_the_repo<br />
<br />
<br />
= Web - items =<br />
<br />
Most important tool is treeherder (https://treeherder.mozilla.org) here we monitor the trees and mark (we call it “star”) test and build failures. While “learning by doing” is the most effective thing, for reading we have created https://wiki.mozilla.org/Sheriffing/How:To:TBPL <br />
<br />
<br />
= The Sheriffs How-To =<br />
<br />
A lot of knowledge about Sheriffing comes from the day-to-day work and you will learn new things and maybe create your own workflow that is maybe better than any current. To share the knowledge about Sheriffing and make it a little easier for people to onboard, we have created the Sheriffs How-To here: https://wiki.mozilla.org/Sheriffing/How:To with a section about various topics. You are also invited to share/create/ new topics or maybe update “old” one with your <br />
experience.<br />
<br />
<br />
= Communication =<br />
<br />
Sheriffs hang out in the #sheriffs channel on irc - also its useful to be in the following Channels<br />
<br />
-> #developers - most of the developers are around here<br />
-> #buildduty - our counterparts of the build system “sheriffs”<br />
-> #releng - general Release Engineering Channel<br />
-> #taskcluster - taskcluster team channel</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Sheriffs_Schedule&diff=1172525Sheriffing/Sheriffs Schedule2017-06-02T13:20:06Z<p>Tomcat: Created page with "= Sheriffs Schedule = Paid Sheriffs: Wesley Kocher and Tomcat = Some remarks: = All times below are Pacific Time based and translated from local Timezones (like Central Eur..."</p>
<hr />
<div>= Sheriffs Schedule = <br />
<br />
Paid Sheriffs: Wesley Kocher and Tomcat<br />
<br />
= Some remarks: =<br />
All times below are Pacific Time based and translated from local Timezones (like Central European Time for Tomcat) etc.<br />
Merges: We try to merge at least 2 times a day - this heavily depend on the state of the Trees. As example changesets for merges need to fullfill certain criteria like green PGO Builds (especially for Windows), free of bustages etc - we cannot merge “what we have” like a changeset without PGO etc - this might work in 99 % of merges but in the 1 % of cases you might cause unintentionally a problem for Nightly Testers like Startup-Crashes and that 1 % case then affects lots of people if we would not follow the criteria rule. So we need to follow quality over quantity here. Also this only applies for workdays - on weekends merges are done on a voluntary base in case someone is around.<br />
<br />
The PGO Builds should be triggered (if not already there) at the beginning of your shift. This increase the possibility that you have a mergeable changeset later even if there are some bustages etc later. Also merging earlier with this changeset allow you to fix problems like conflicts/issues on m-c after merge.<br />
Sheriff coverage<br />
Tomcat’s Coverage: Based in Europe (Munich Area) from 11pm - 8am, so covering Parts of Asia, Europe and parts of East Cost <br />
KWierso’s Coverage: Based in Oregon from 9am - 5pm, covering US daytime<br />
<br />
= Timetable =<br />
<br />
12am - Tomcat|sheriffduty - Uplifts, Checkin-needed, Tree Monitoring etc <br />
1am - Tomcat|sheriffduty - Tree Monitoring Uplifts - Merge work<br />
2am - Tomcat|sheriffduty - Tree Monitoring Uplifts - Bughunter <br />
3am - Nightly Builds for Mozilla-central starts - <br />
4am - Tomcat one hour lunch break <br />
5am - Tomcat|sheriffduty, Tree Monitoring <br />
6am - Tomcat|sheriffduty, Tree Monitoring<br />
7am - Tomcat|sheriffduty, Tree Monitoring<br />
8am - Tomcat|sheriffduty, Tree Monitoring<br />
9am - KWierso, Tree Monitoring<br />
10am - KWierso, Tree Monitoring<br />
11am - KWierso, Tree Monitoring<br />
12pm - KWierso, Lunch<br />
1pm - KWierso, Tree Monitoring<br />
2pm - KWierso, Tree Monitoring<br />
3pm - KWierso, Tree Monitoring - Merge work<br />
4pm - KWierso, Tree Monitoring<br />
5pm - KWierso, Tree Monitoring<br />
6pm - #sheriffs<br />
7pm - #sheriffs<br />
8pm - #sheriffs<br />
9pm - #sheriffs<br />
10pm -#sheriffs<br />
11pm - Tomcat|sheriffduty</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How:To:DayOne&diff=1172522Sheriffing/How:To:DayOne2017-06-02T13:15:08Z<p>Tomcat: Created page with "'''Bold text'''Day one Checklist = “Software Requirements” = Up to do Mercurial Installation either from https://www.mercurial-scm.org/downloads or the download source o..."</p>
<hr />
<div>'''Bold text'''Day one Checklist<br />
<br />
= “Software Requirements” =<br />
<br />
Up to do Mercurial Installation either from https://www.mercurial-scm.org/downloads or the download source of your choice <br />
Make sure you read https://developer.mozilla.org/de/docs/Installing_Mercurial<br />
A clone of the mozilla-central, mozilla-inbound, autoland code-tree (https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Source_Code/Mercurial can be helpful) <br />
or/and <br />
A unified repo - steps to set this up are here -> https://wiki.mozilla.org/Sheriffing/How:To:SheriffingFromUnifiedRepos#Setting_up_the_repo<br />
<br />
<br />
= Web - items =<br />
<br />
Most important tool is treeherder (https://treeherder.mozilla.org) here we monitor the trees and mark (we call it “star”) test and build failures. While “learning by doing” is the most effective thing, for reading we have created https://wiki.mozilla.org/Sheriffing/How:To:TBPL <br />
<br />
<br />
= The Sheriffs How-To =<br />
<br />
A lot of knowledge about Sheriffing comes from the day-to-day work and you will learn new things and maybe create your own workflow that is maybe better than any current. To share the knowledge about Sheriffing and make it a little easier for people to onboard, we have created the Sheriffs How-To here: https://wiki.mozilla.org/Sheriffing/How:To with a section about various topics. You are also invited to share/create/ new topics or maybe update “old” one with your <br />
experience.<br />
<br />
<br />
= Communication =<br />
<br />
Sheriffs hang out in the #sheriffs channel on irc - also its useful to be in the following Channels<br />
<br />
-> #developers - most of the developers are around here<br />
-> #buildduty - our counterparts of the build system “sheriffs”<br />
-> #releng - general Release Engineering Channel<br />
-> #taskcluster - taskcluster team channel</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Bisecting&diff=1172521Sheriffing/How To/Bisecting2017-06-02T13:13:07Z<p>Tomcat: Created page with "'''Bisecting''' Sheriffs are doing bisecting to find out what changeset cause a failure if we can’t determine this via code inspection. = Fictitious Scenario: = After a m..."</p>
<hr />
<div>'''Bisecting'''<br />
<br />
Sheriffs are doing bisecting to find out what changeset cause a failure if we can’t determine this via code inspection.<br />
<br />
= Fictitious Scenario: =<br />
<br />
After a merge from integration to m-c the the xpcshell tests on linux-asan are busted and it’s not clear which changeset cause - inbound and autoland were fine.<br />
<br />
== '''So the Sheriff on duty starts bisecting:''' ==<br />
<br />
Changes of the merge (complete Fictitious)<br />
<br />
2c497462f25e Merge inbound to m-c a=merge<br />
02851079c451Bug 1359458 - Increase assertion count range for test_bug437844.xul. r=jmaher<br />
B37b46c7f38f Bug 1358241 - [2.1] Add mutex locking around the library handles cache. r=jchen<br />
751455b663d0 Bug 1358241 - [1.2] Make direct library reference counter atomic to avoid mutex locking issues. r=jchen<br />
841fa5fb06a8 Bug 1355676 - Check for nulls when decoding icons. r=sebastian<br />
Ad9d525e6db7 Bug 1356243 - Enable Screenshots by default. r=Mossop<br />
2e44294b9f5c Bug 1359273 - Split up DevTools' sort-arrows.svg to improve performance. r=jryans<br />
<br />
== '''Requirements for bisecting''' ==<br />
<br />
-> Clone mozilla-central<br />
-> Add the try server settings (see https://wiki.mozilla.org/ReleaseEngineering/TryServer#Configuration )<br />
-> Find the try syntax (trychooser might be a big help). In this scenario its try: -b o -p linux64-asan -u xpcshell -t none --rebuild 10 <br />
(The rebuild 10 means that you basically run the xpcshell tests 10 times and not once)<br />
<br />
== '''First step:''' ==<br />
<br />
To make sure/give yourself confirmation that you set everything up correctly and that you can reproduce the problem on try, do a try push with m-c tip as topmost revision.<br />
<br />
Make a dummy change (like touch clobber or so to have a change).<br />
Commit with something like -m “central tip try: -b o -p linux64-asan -u xpcshell -t none --rebuild 10”<br />
Push to try<br />
Check that you get the same failure etc<br />
<br />
== '''Second Step - now bisecting begins''' ==<br />
<br />
Now it’s on you to start bisecting.<br />
<br />
There are several approaches possible, one would be to split up the merge and check if the test failure already starts in the middle of the merge. So you decide to run a try run with 841fa5fb06a8 as topmost revision.<br />
<br />
<br />
-> hg up -r 841fa5fb06a8 to update to the older topmost rev<br />
-> you can confirm this with doing: hg summary and it should show something like <br />
parent: 354839:841fa5fb06a8<br />
Bug 1355676 - Check for nulls when decoding icons. r=sebastian<br />
<br />
-> hg commit -m "central rev 841fa5fb06a8 try: -b o -p linux64-asan -u xpcshell -t none --rebuild 10" <br />
<br />
-> push to try<br />
<br />
-> Check the results - let’s assume results for 841fa5fb06a8 are green, so you need to do the same steps again for the latter changes (02851079c451 and B37b46c7f38f / 751455b663d0 ) to check which of this 2 bugs cause the problem.<br />
<br />
<br />
Note: in case of bisecting for an actual issue you can push up to 6 pushes to try at the same time to be able to have results asap.</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Merges&diff=1168682Sheriffing/How To/Merges2017-04-19T06:53:38Z<p>Tomcat: </p>
<hr />
<div>'''Merges:''' <br />
<br />
''Goal: Merging around twice a day to/from autoland and mozilla-inbound to mozilla-central''<br />
<br />
'''Merges from the integration trees to mozilla-central are done on green PGO runs to avoid bustages on PGO which could affect as example Nightly Builds'''<br />
<br />
<br />
= Step 1= <br />
Merging from autoland and mozilla-inbound to mozilla-central<br />
<br />
Example mozilla-inbound to mozilla-central merge<br />
-> cd into your mozilla-central directory<br />
-> hg pull ssh://hg.mozilla.org/integration/mozilla-inbound -r (the green with PGO runs inbound revision changeset) - also make sure there are no backouts after that etc<br />
-> hg merge && hg commit -m "merge inbound to mozilla-central"<br />
-> push<br />
<br />
'''don't forget to use Bugherder after that! It's available from the menu for the push on [https://treeherder.mozilla.org/#/jobs?repo=mozilla-central Treeherder]'''<br />
<br />
= Step 2 =<br />
Merging back from mozilla-central to autoland and mozilla-inbound<br />
<br />
Example mozilla-central to mozilla-inbound merge<br />
-> go to your mozilla-inbound tree directory<br />
-> hg pull && hg update to make sure its the latest<br />
-> hg pull ssh://hg.mozilla.org/mozilla-central/<br />
-> hg merge<br />
-> hg commit -m "merge mozilla-central to mozilla-inbound"<br />
-> hg push<br />
since this above might result in race conditions on the tree <br />
(when its busy there) this works better -> <br />
go to your mozilla-inbound tree<br />
hg pull && hg update && hg pull ssh://hg.mozilla.org/mozilla-central/ && hg merge && hg commit -m "Merge mozilla-central to [TREENAME]" && hg push <br />
<br />
Aliases for the various repositories make the above easier to type!<br />
<br />
= Step 3 hg update when there is nothing to merge =<br />
<br />
You get the run 'hg update' to get a working copy information, because there where no changes on m-c and so nothing to merge. The workflow for this case is:<br />
<br />
1.) Run hg update<br />
-- If unsure if everything is ok just do a hg out, that should list all the changesets you want to sync to m-c<br />
<br />
2.) because you do no merge and so have no commits like "merge a to b a=me" you would run into a hg hook telling you that the m-c repo is set to approval-only - so you need to temporary need to set the mozilla-central tree to "open" via tree-status to be able to push<br />
<br />
3.) Push your changes from Step 1<br />
<br />
4.) Set the m-c tree back to approval-required. This is important because if we miss this, we risk unexpected pushes to mozilla-central since some people might think the open tree is intentional :)<br />
<br />
5.) Use Bugherder to mark the bugs as usual<br />
<br />
6.) now when you do the Steps from Step 1 with mozilla-inbound you get the note that you need to merge.</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Merges&diff=1168681Sheriffing/How To/Merges2017-04-19T06:47:46Z<p>Tomcat: </p>
<hr />
<div>'''Merges:''' <br />
<br />
''Merging around twice a day to/from autoland and mozilla-inbound to mozilla-central''<br />
<br />
'''Merges from the integration trees to mozilla-central are done on green PGO runs to avoid bustages on PGO which could affect as example Nightly Builds'''<br />
<br />
<br />
= Step 1= <br />
Merging from autoland and mozilla-inbound to mozilla-central<br />
<br />
Example mozilla-inbound to mozilla-central merge<br />
-> cd into your mozilla-central directory<br />
-> hg pull ssh://hg.mozilla.org/integration/mozilla-inbound -r (the green with PGO runs inbound revision changeset) - also make sure there are no backouts after that etc<br />
-> hg merge && hg commit -m "merge inbound to mozilla-central"<br />
-> push<br />
<br />
'''don't forget to use Bugherder after that! It's available from the menu for the push on [https://treeherder.mozilla.org/#/jobs?repo=mozilla-central Treeherder]'''<br />
<br />
= Step 2 =<br />
Merging back from mozilla-central to autoland and mozilla-inbound<br />
<br />
Example mozilla-central to mozilla-inbound merge<br />
-> go to your mozilla-inbound tree directory<br />
-> hg pull && hg update to make sure its the latest<br />
-> hg pull ssh://hg.mozilla.org/mozilla-central/<br />
-> hg merge<br />
-> hg commit -m "merge mozilla-central to mozilla-inbound"<br />
-> hg push<br />
since this above might result in race conditions on the tree <br />
(when its busy there) this works better -> <br />
go to your mozilla-inbound tree<br />
hg pull && hg update && hg pull ssh://hg.mozilla.org/mozilla-central/ && hg merge && hg commit -m "Merge mozilla-central to [TREENAME]" && hg push <br />
<br />
Aliases for the various repositories make the above easier to type!<br />
<br />
= Step 3 hg update when there is nothing to merge =<br />
<br />
You get the run 'hg update' to get a working copy information, because there where no changes on m-c and so nothing to merge. The workflow for this case is:<br />
<br />
1.) Run hg update<br />
-- If unsure if everything is ok just do a hg out, that should list all the changesets you want to sync to m-c<br />
<br />
2.) because you do no merge and so have no commits like "merge a to b a=me" you would run into a hg hook telling you that the m-c repo is set to approval-only - so you need to temporary need to set the mozilla-central tree to "open" via tree-status to be able to push<br />
<br />
3.) Push your changes from Step 1<br />
<br />
4.) Set the m-c tree back to approval-required. This is important because if we miss this, we risk unexpected pushes to mozilla-central since some people might think the open tree is intentional :)<br />
<br />
5.) Use Bugherder to mark the bugs as usual<br />
<br />
6.) now when you do the Steps from Step 1 with mozilla-inbound you get the note that you need to merge.</div>Tomcathttps://wiki.mozilla.org/index.php?title=EngineeringProductivity/Meetings/2017-02-06&diff=1161956EngineeringProductivity/Meetings/2017-02-062017-02-06T14:02:38Z<p>Tomcat: /* Newsgroup and Blog Posts */</p>
<hr />
<div>= Notices, Highlights, Roundtable =<br />
* Significant Contributions<br />
<br />
= Newsgroup and Blog Posts =<br />
About: Sheriffing - January Edition :) https://groups.google.com/forum/#!topic/mozilla.dev.platform/1Yobxt-5vjc<br />
<br />
= Goal Updates =<br />
<br />
= Other Project Updates =<br />
<br />
= Holidays and Trips =<br />
<br />
= Misc =</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Outage_Notice&diff=1155202Sheriffing/Outage Notice2016-11-18T08:48:25Z<p>Tomcat: </p>
<hr />
<div>=== DRAFT ===<br />
<br />
Note this is a draft and more concept idea - so work in progress<br />
<br />
=== Introduction ===<br />
<br />
Development Work at Mozilla depend a lot on open Trees like Mozilla-Inbound, Fx-Team and even Mozilla-Try. Sheriffs maintain and control the Status of the Trees and Close Trees if needed. <br />
<br />
Mostly this Tree-Closures are due failing Code (like Build Bustages, Test failures) and are this Tree Closures are normally fixed very temporary. However we might have cases where we have longer Tree-Closures due to Infra Related Problems that are UN-planned and need deeper investigations by Teams like IT,Releng, Taskcluster etc<br />
<br />
For this cases we might need notifications to Developers to :<br />
<br />
<br />
* Avoid frustrations when people want to push to try and notice its not possible<br />
* Pending/Running Testruns (especially try) fails to whatever unrelated reasons and cause a Developer to spend time on issues that are not caused by her/his changes<br />
* Reduce hammering on Sheriffs why a tree is closed and whats the eta etc<br />
<br />
=== Steps to-do from the onduty Sheriff ===<br />
<br />
1.) make clear that there is a outage and who is the current Sheriff with changing the topic of the #developers channel on IRC. Please add also the tracking bug and a possible eta time into the topic of #developers.<br />
<br />
example:<br />
Onduty-Sheriff: Tomcat - All Tree Closure - Database issue Bug 1234567 - no eta yet<br />
<br />
2. Also post to #treestatus about the tree closure <br />
<br />
3.) If the tree closures is expect to be a longer problem -> Post a short mail to the mozilla.dev.platform and dev-fxos <dev-fxos@lists.mozilla.org> newsgroup like https://groups.google.com/forum/#!topic/mozilla.dev.platform/Kzd1es4KiYA - also like here the next sheriff could if the issue is fixed sent a all clear information.</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Uplifts&diff=1154129Sheriffing/How To/Uplifts2016-11-09T08:38:11Z<p>Tomcat: </p>
<hr />
<div>Standard practice is that bug fixes that affect the release branches must first land on trunk/master. Unless there is a branch-specific patch attached to the bug, the patch that landed must then be transplanted to the appropriate branches. This page documents the procedure for performing those uplifts for both Gecko and Gaia.<br />
<br />
= Prerequisites =<br />
To perform uplifts with Mercurial, either the native [http://www.selenic.com/hg/help/graft graft] command or the [http://mercurial.selenic.com/wiki/TransplantExtension transplant] extension needs to be enabled, depending on how the different branches are cloned. Git has native [http://www.git-scm.com/docs/git-cherry-pick cherry-pick] functionality that can be used for all Gaia uplifts (or Gecko if using the Git mirror).<br />
<br />
== Gecko Uplifts ==<br />
=== Using Separate Repositories ===<br />
By default, the different Gecko branches live in different repositories. With multiple repos, the transplant extension is the preferred method. Creating an [http://www.selenic.com/mercurial/hgrc.5.html#alias alias] simplifies the process for transplanting a given revision <b>(or revset)</b>.<br />
# Transplant a cset from the specified branch to the current branch and edit the commit message.<br />
# *** This assumes that local clones are named mozilla-XXX (aurora, beta, etc). ***<br />
# Usage: hg uplift &#60;source&#62; &#60;rev&#62;<br />
# Example: hg uplift aurora abc123abc123<br />
uplift = transplant -e -s ../mozilla-$1 $2<br />
<br />
Optionally, an mq-based alias can also be created, which exports a specified revision from the current clone and imports it into another.<br />
# Export a cset from the current branch to the specified branch, add it to the queue, attempt to apply it, and edit the commit message.<br />
# *** This assumes that local clones are named mozilla-XXX (aurora, beta, etc). ***<br />
# Usage: hg uplift-mq &#60;branch&#62; &#60;bug#&#62; &#60;rev&#62;<br />
# Example: hg uplift-mq aurora 123456 abc123abc123<br />
uplift-mq = !hg export -r $3 > ../mozilla-$1/.hg/patches/$2 && cd ../mozilla-$1 && hg qimport -e -P $2 && hg qref -e<br />
<br />
<b>NOTE: The above aliases work in opposite directions!</b><br />
<br />
=== Using A Unified Repository ===<br />
When using the [http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html Firefoxtree] extension, all the Gecko releases live in the same repository. The native graft function can be used.<br />
hg graft -er &#60;rev&#62;<br />
<br />
= Uplift Procedure =<br />
* Unless specifically cleared by Release Management, patches should land on mozilla-central prior to being uplifted elsewhere.<br />
* Patches should be uplifted from the most-recent version to the oldest (i.e. Aurora -> Beta -> etc or v2.2 -> v2.1 -> etc). This will help minimize rebasing pain.<br />
* To avoid conflicts, patches should be transplanted from oldest to newest. The search queries below default to sorting in the order the bugs were resolved.<br />
** Until bug 1154728 is resolved, note that Bugherder marks bugs in the *opposite* order of which they landed!<br />
* If there is a branch-specific patch attached to the bug, use that. Otherwise, transplant it using the methods shown in the section above.<br />
* Add a=<whoever approved> to the commit message.<br />
* After pushing, mark the bugs and set the appropriate status flags. The Bugherder tool available from the dropdown on the right side of each push on Treeherder can automate this process.<br />
<br />
= Bug Queries =<br />
The [https://bugzilla.mozilla.org/page.cgi?id=release_tracking_report.html Release Tracking Report] has some useful bug queries. However, it has limitations in that it only sees bugs that have a status of "affected", "fixed", or "verified" set. As a result, it will miss approved bugs if no status is set ("---") and will show bugs as still needing uplift if their status is an unexpected value (like "disabled"). As a result, a combination of this report and the queries below is recommended to avoid missing bugs.<br />
<br />
== B2G ==<br />
Bug queries are on the [https://wiki.mozilla.org/Release_Management/B2G_Landing#Automatic_Branch_Uplifts B2G Landing] page.<br />
<br />
== ESR ==<br />
The ESR intermittent queries are *very* useful for looking at recently-fixed intermittent failure bugs and ensuring that status flags are set for all applicable releases. The [https://wiki.mozilla.org/RapidRelease/Calendar Release Calendar] can help determine in which release an intermittent first appeared (in addition to looking at Treeherderbot comments in the bug).<br />
<br />
<b>ESR45</b><br />
<br />
[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;field0-0-0=flagtypes.name;type0-0-0=equals;value0-0-0=approval-mozilla-esr45%2B;field0-1-0=cf_status_firefox_esr45;type0-1-0=nowordssubstr;value0-1-0=fixed%20verified%20wontfix%20unaffected%20disabled All esr45 approvals not yet uplifted]<br />
<br />
[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved&resolution=FIXED&keywords=intermittent-failure&keywords_type=allwords&field0-0-0=cf_last_resolved&type0-0-0=greaterthaneq&value0-0-0=2015-08-30&field0-1-0=product&type0-1-0=nowordssubstr&value0-1-0=Calendar%20Chat%20MailNews%20QA%20Thunderbird%20Release&field0-2-0=component&type0-2-0=nowordssubstr&value0-2-0=Gaia&field0-3-0=cf_status_firefox_esr45&type0-3-0=nowordssubstr&value0-3-0=fixed%20verified%20wontfix%20unaffected%20disabled Fixed intermittents w/o esr45 {fixed|verified|wontfix|unaffected|disabled}]<br />
<br />
= Best Practice =<br />
<br />
* Use a unified tree https://wiki.mozilla.org/Sheriffing/How:To:SheriffingFromUnifiedRepos can help you with that<br />
* Use the queries from release_tracking_report to find Bugs to uplift as example<br />
as example "show where approval-mozilla-aurora was changed to approval + between - use custom dates <br />
set the current status of the current aurora version as unfixed like status mozilla-51 not fixed<br />
* Use the Resulting Bugs to uplift <br />
<br />
* If you have patches like a rebased - aurora patch where a straight uplift from mozilla-central to like aurora don't work see https://wiki.mozilla.org/Sheriffing/How:To:SheriffingFromUnifiedRepos#Single_repository_and_single_set_of_patches<br />
<br />
* As example for a aurora uplift from mozilla-central<br />
Pull and update to prepare for the uplifts:<br />
hg pull central<br />
hg pull aurora<br />
hg up aurora<br />
<br />
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:<br />
hg graft --edit -r <revision><br />
<br />
Repeat the previous step as needed for all uplifts as needed. Verify the outgoing changes and push:<br />
hg out -r . aurora<br />
hg push -r . aurora</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Uplift-Sim&diff=1153075Sheriffing/Uplift-Sim2016-10-31T15:53:13Z<p>Tomcat: </p>
<hr />
<div>In order to prevent long Tree-Closures after Release Merge Day, Sheriffs are now doing regular simulations of Code Merges from like Trunk -> Aurora, Aurora -> Beta and Trunk -> Beta<br />
<br />
The steps how to do this Simulations are documented here :<br />
<br />
<br />
* [[Sheriffing/Uplift-Sim/Bump-Trunk|Bump Version Numbers on trunk]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora|Trunk-> Aurora]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora-Nightly|Simulate use Aurora update channel like Aurora nightlies]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Beta|Trunk to Beta]]<br />
* [[Sheriffing/Uplift-Sim//Beta-Release|Use Beta update channel like Beta release builds ]]<br />
* [[Sheriffing/Uplift-Sim/Aurora-Beta|Aurora-Beta]]<br />
<br />
Also configs are in https://bugzilla.mozilla.org/show_bug.cgi?id=1280663<br />
<br />
Results for the Try runs are here :<br />
<br />
https://treeherder.mozilla.org/#/jobs?repo=try&author=cbook@mozilla.com</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Uplifts&diff=1153055Sheriffing/How To/Uplifts2016-10-31T11:44:23Z<p>Tomcat: </p>
<hr />
<div>Standard practice is that bug fixes that affect the release branches must first land on trunk/master. Unless there is a branch-specific patch attached to the bug, the patch that landed must then be transplanted to the appropriate branches. This page documents the procedure for performing those uplifts for both Gecko and Gaia.<br />
<br />
= Prerequisites =<br />
To perform uplifts with Mercurial, either the native [http://www.selenic.com/hg/help/graft graft] command or the [http://mercurial.selenic.com/wiki/TransplantExtension transplant] extension needs to be enabled, depending on how the different branches are cloned. Git has native [http://www.git-scm.com/docs/git-cherry-pick cherry-pick] functionality that can be used for all Gaia uplifts (or Gecko if using the Git mirror).<br />
<br />
== Gecko Uplifts ==<br />
=== Using Separate Repositories ===<br />
By default, the different Gecko branches live in different repositories. With multiple repos, the transplant extension is the preferred method. Creating an [http://www.selenic.com/mercurial/hgrc.5.html#alias alias] simplifies the process for transplanting a given revision <b>(or revset)</b>.<br />
# Transplant a cset from the specified branch to the current branch and edit the commit message.<br />
# *** This assumes that local clones are named mozilla-XXX (aurora, beta, etc). ***<br />
# Usage: hg uplift &#60;source&#62; &#60;rev&#62;<br />
# Example: hg uplift aurora abc123abc123<br />
uplift = transplant -e -s ../mozilla-$1 $2<br />
<br />
Optionally, an mq-based alias can also be created, which exports a specified revision from the current clone and imports it into another.<br />
# Export a cset from the current branch to the specified branch, add it to the queue, attempt to apply it, and edit the commit message.<br />
# *** This assumes that local clones are named mozilla-XXX (aurora, beta, etc). ***<br />
# Usage: hg uplift-mq &#60;branch&#62; &#60;bug#&#62; &#60;rev&#62;<br />
# Example: hg uplift-mq aurora 123456 abc123abc123<br />
uplift-mq = !hg export -r $3 > ../mozilla-$1/.hg/patches/$2 && cd ../mozilla-$1 && hg qimport -e -P $2 && hg qref -e<br />
<br />
<b>NOTE: The above aliases work in opposite directions!</b><br />
<br />
=== Using A Unified Repository ===<br />
When using the [http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html Firefoxtree] extension, all the Gecko releases live in the same repository. The native graft function can be used.<br />
hg graft -er &#60;rev&#62;<br />
<br />
= Uplift Procedure =<br />
* Unless specifically cleared by Release Management, patches should land on mozilla-central prior to being uplifted elsewhere.<br />
* Patches should be uplifted from the most-recent version to the oldest (i.e. Aurora -> Beta -> etc or v2.2 -> v2.1 -> etc). This will help minimize rebasing pain.<br />
* To avoid conflicts, patches should be transplanted from oldest to newest. The search queries below default to sorting in the order the bugs were resolved.<br />
** Until bug 1154728 is resolved, note that Bugherder marks bugs in the *opposite* order of which they landed!<br />
* If there is a branch-specific patch attached to the bug, use that. Otherwise, transplant it using the methods shown in the section above.<br />
* Add a=<whoever approved> to the commit message.<br />
* After pushing, mark the bugs and set the appropriate status flags. The Bugherder tool available from the dropdown on the right side of each push on Treeherder can automate this process.<br />
<br />
= Bug Queries =<br />
The [https://bugzilla.mozilla.org/page.cgi?id=release_tracking_report.html Release Tracking Report] has some useful bug queries. However, it has limitations in that it only sees bugs that have a status of "affected", "fixed", or "verified" set. As a result, it will miss approved bugs if no status is set ("---") and will show bugs as still needing uplift if their status is an unexpected value (like "disabled"). As a result, a combination of this report and the queries below is recommended to avoid missing bugs.<br />
<br />
== B2G ==<br />
Bug queries are on the [https://wiki.mozilla.org/Release_Management/B2G_Landing#Automatic_Branch_Uplifts B2G Landing] page.<br />
<br />
== ESR ==<br />
The ESR intermittent queries are *very* useful for looking at recently-fixed intermittent failure bugs and ensuring that status flags are set for all applicable releases. The [https://wiki.mozilla.org/RapidRelease/Calendar Release Calendar] can help determine in which release an intermittent first appeared (in addition to looking at Treeherderbot comments in the bug).<br />
<br />
<b>ESR45</b><br />
<br />
[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;field0-0-0=flagtypes.name;type0-0-0=equals;value0-0-0=approval-mozilla-esr45%2B;field0-1-0=cf_status_firefox_esr45;type0-1-0=nowordssubstr;value0-1-0=fixed%20verified%20wontfix%20unaffected%20disabled All esr45 approvals not yet uplifted]<br />
<br />
[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved&resolution=FIXED&keywords=intermittent-failure&keywords_type=allwords&field0-0-0=cf_last_resolved&type0-0-0=greaterthaneq&value0-0-0=2015-08-30&field0-1-0=product&type0-1-0=nowordssubstr&value0-1-0=Calendar%20Chat%20MailNews%20QA%20Thunderbird%20Release&field0-2-0=component&type0-2-0=nowordssubstr&value0-2-0=Gaia&field0-3-0=cf_status_firefox_esr45&type0-3-0=nowordssubstr&value0-3-0=fixed%20verified%20wontfix%20unaffected%20disabled Fixed intermittents w/o esr45 {fixed|verified|wontfix|unaffected|disabled}]<br />
<br />
= Best Practice =<br />
<br />
* Use a unified tree https://wiki.mozilla.org/Sheriffing/How:To:SheriffingFromUnifiedRepos can help you with that<br />
* Use the queries from release_tracking_report to find Bugs to uplift as example<br />
as example "show where approval-mozilla-aurora was changed to approval + between - use custom dates <br />
set the current status of the current aurora version as unfixed like status mozilla-51 not fixed<br />
* Use the Resulting Bugs to uplift <br />
<br />
* As example for a aurora uplift<br />
Pull and update to prepare for the uplifts:<br />
hg pull central<br />
hg pull aurora<br />
hg up aurora<br />
<br />
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:<br />
hg graft --edit -r <revision><br />
<br />
Repeat the previous step as needed for all uplifts as needed. Verify the outgoing changes and push:<br />
hg out -r . aurora<br />
hg push -r . aurora</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Uplifts&diff=1153054Sheriffing/How To/Uplifts2016-10-31T08:56:27Z<p>Tomcat: </p>
<hr />
<div>Standard practice is that bug fixes that affect the release branches must first land on trunk/master. Unless there is a branch-specific patch attached to the bug, the patch that landed must then be transplanted to the appropriate branches. This page documents the procedure for performing those uplifts for both Gecko and Gaia.<br />
<br />
= Prerequisites =<br />
To perform uplifts with Mercurial, either the native [http://www.selenic.com/hg/help/graft graft] command or the [http://mercurial.selenic.com/wiki/TransplantExtension transplant] extension needs to be enabled, depending on how the different branches are cloned. Git has native [http://www.git-scm.com/docs/git-cherry-pick cherry-pick] functionality that can be used for all Gaia uplifts (or Gecko if using the Git mirror).<br />
<br />
== Gecko Uplifts ==<br />
=== Using Separate Repositories ===<br />
By default, the different Gecko branches live in different repositories. With multiple repos, the transplant extension is the preferred method. Creating an [http://www.selenic.com/mercurial/hgrc.5.html#alias alias] simplifies the process for transplanting a given revision <b>(or revset)</b>.<br />
# Transplant a cset from the specified branch to the current branch and edit the commit message.<br />
# *** This assumes that local clones are named mozilla-XXX (aurora, beta, etc). ***<br />
# Usage: hg uplift &#60;source&#62; &#60;rev&#62;<br />
# Example: hg uplift aurora abc123abc123<br />
uplift = transplant -e -s ../mozilla-$1 $2<br />
<br />
Optionally, an mq-based alias can also be created, which exports a specified revision from the current clone and imports it into another.<br />
# Export a cset from the current branch to the specified branch, add it to the queue, attempt to apply it, and edit the commit message.<br />
# *** This assumes that local clones are named mozilla-XXX (aurora, beta, etc). ***<br />
# Usage: hg uplift-mq &#60;branch&#62; &#60;bug#&#62; &#60;rev&#62;<br />
# Example: hg uplift-mq aurora 123456 abc123abc123<br />
uplift-mq = !hg export -r $3 > ../mozilla-$1/.hg/patches/$2 && cd ../mozilla-$1 && hg qimport -e -P $2 && hg qref -e<br />
<br />
<b>NOTE: The above aliases work in opposite directions!</b><br />
<br />
=== Using A Unified Repository ===<br />
When using the [http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html Firefoxtree] extension, all the Gecko releases live in the same repository. The native graft function can be used.<br />
hg graft -er &#60;rev&#62;<br />
<br />
= Uplift Procedure =<br />
* Unless specifically cleared by Release Management, patches should land on mozilla-central prior to being uplifted elsewhere.<br />
* Patches should be uplifted from the most-recent version to the oldest (i.e. Aurora -> Beta -> etc or v2.2 -> v2.1 -> etc). This will help minimize rebasing pain.<br />
* To avoid conflicts, patches should be transplanted from oldest to newest. The search queries below default to sorting in the order the bugs were resolved.<br />
** Until bug 1154728 is resolved, note that Bugherder marks bugs in the *opposite* order of which they landed!<br />
* If there is a branch-specific patch attached to the bug, use that. Otherwise, transplant it using the methods shown in the section above.<br />
* Add a=<whoever approved> to the commit message.<br />
* After pushing, mark the bugs and set the appropriate status flags. The Bugherder tool available from the dropdown on the right side of each push on Treeherder can automate this process.<br />
<br />
= Bug Queries =<br />
The [https://bugzilla.mozilla.org/page.cgi?id=release_tracking_report.html Release Tracking Report] has some useful bug queries. However, it has limitations in that it only sees bugs that have a status of "affected", "fixed", or "verified" set. As a result, it will miss approved bugs if no status is set ("---") and will show bugs as still needing uplift if their status is an unexpected value (like "disabled"). As a result, a combination of this report and the queries below is recommended to avoid missing bugs.<br />
<br />
== B2G ==<br />
Bug queries are on the [https://wiki.mozilla.org/Release_Management/B2G_Landing#Automatic_Branch_Uplifts B2G Landing] page.<br />
<br />
== ESR ==<br />
The ESR intermittent queries are *very* useful for looking at recently-fixed intermittent failure bugs and ensuring that status flags are set for all applicable releases. The [https://wiki.mozilla.org/RapidRelease/Calendar Release Calendar] can help determine in which release an intermittent first appeared (in addition to looking at Treeherderbot comments in the bug).<br />
<br />
<b>ESR45</b><br />
<br />
[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;field0-0-0=flagtypes.name;type0-0-0=equals;value0-0-0=approval-mozilla-esr45%2B;field0-1-0=cf_status_firefox_esr45;type0-1-0=nowordssubstr;value0-1-0=fixed%20verified%20wontfix%20unaffected%20disabled All esr45 approvals not yet uplifted]<br />
<br />
[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved&resolution=FIXED&keywords=intermittent-failure&keywords_type=allwords&field0-0-0=cf_last_resolved&type0-0-0=greaterthaneq&value0-0-0=2015-08-30&field0-1-0=product&type0-1-0=nowordssubstr&value0-1-0=Calendar%20Chat%20MailNews%20QA%20Thunderbird%20Release&field0-2-0=component&type0-2-0=nowordssubstr&value0-2-0=Gaia&field0-3-0=cf_status_firefox_esr45&type0-3-0=nowordssubstr&value0-3-0=fixed%20verified%20wontfix%20unaffected%20disabled Fixed intermittents w/o esr45 {fixed|verified|wontfix|unaffected|disabled}]<br />
<br />
= Best Practicse =<br />
<br />
* Use a unified tree https://wiki.mozilla.org/Sheriffing/How:To:SheriffingFromUnifiedRepos can help you with that<br />
* Use the queries from release_tracking_report to find Bugs to uplift as example<br />
as example "show where approval-mozilla-aurora was changed to approval + between - use custom dates <br />
set the current status of the current aurora version as unfixed like status mozilla-51 not fixed<br />
* Use the Resulting Bugs to uplift <br />
<br />
* As example for a aurora uplift<br />
Pull and update to prepare for the uplifts:<br />
hg pull central<br />
hg pull aurora<br />
hg up aurora<br />
<br />
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:<br />
hg graft --edit -r <revision><br />
<br />
Repeat the previous step as needed for all uplifts as needed. Verify the outgoing changes and push:<br />
hg out -r . aurora<br />
hg push -r . aurora</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Uplifts&diff=1153051Sheriffing/How To/Uplifts2016-10-31T08:47:42Z<p>Tomcat: </p>
<hr />
<div>Standard practice is that bug fixes that affect the release branches must first land on trunk/master. Unless there is a branch-specific patch attached to the bug, the patch that landed must then be transplanted to the appropriate branches. This page documents the procedure for performing those uplifts for both Gecko and Gaia.<br />
<br />
= Prerequisites =<br />
To perform uplifts with Mercurial, either the native [http://www.selenic.com/hg/help/graft graft] command or the [http://mercurial.selenic.com/wiki/TransplantExtension transplant] extension needs to be enabled, depending on how the different branches are cloned. Git has native [http://www.git-scm.com/docs/git-cherry-pick cherry-pick] functionality that can be used for all Gaia uplifts (or Gecko if using the Git mirror).<br />
<br />
== Gecko Uplifts ==<br />
=== Using Separate Repositories ===<br />
By default, the different Gecko branches live in different repositories. With multiple repos, the transplant extension is the preferred method. Creating an [http://www.selenic.com/mercurial/hgrc.5.html#alias alias] simplifies the process for transplanting a given revision <b>(or revset)</b>.<br />
# Transplant a cset from the specified branch to the current branch and edit the commit message.<br />
# *** This assumes that local clones are named mozilla-XXX (aurora, beta, etc). ***<br />
# Usage: hg uplift &#60;source&#62; &#60;rev&#62;<br />
# Example: hg uplift aurora abc123abc123<br />
uplift = transplant -e -s ../mozilla-$1 $2<br />
<br />
Optionally, an mq-based alias can also be created, which exports a specified revision from the current clone and imports it into another.<br />
# Export a cset from the current branch to the specified branch, add it to the queue, attempt to apply it, and edit the commit message.<br />
# *** This assumes that local clones are named mozilla-XXX (aurora, beta, etc). ***<br />
# Usage: hg uplift-mq &#60;branch&#62; &#60;bug#&#62; &#60;rev&#62;<br />
# Example: hg uplift-mq aurora 123456 abc123abc123<br />
uplift-mq = !hg export -r $3 > ../mozilla-$1/.hg/patches/$2 && cd ../mozilla-$1 && hg qimport -e -P $2 && hg qref -e<br />
<br />
<b>NOTE: The above aliases work in opposite directions!</b><br />
<br />
=== Using A Unified Repository ===<br />
When using the [http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html Firefoxtree] extension, all the Gecko releases live in the same repository. The native graft function can be used.<br />
hg graft -er &#60;rev&#62;<br />
<br />
== Gaia Uplifts ==<br />
Git has built-in tools for performing transplants, via the cherry-pick function. Since all Gaia branches live in the same repository, we can use that.<br />
git cherry-pick &#60;rev&#62;<br />
If cherry-picking a pull request merge commit, the -m 1 option must be included. For blame purposes, it is preferable to avoid these commits where possible, however.<br />
git cherry-pick -m 1 &#60;rev&#62;<br />
If the pull request only merged one commit, the parent commit can be cherry-picked. If there were multiple commits contained in the pull request, the merge commit can be used instead. Verify that the commit information such as author is set correctly and adjust using |git commit --amend| if necessary.<br />
<br />
= Uplift Procedure =<br />
* Unless specifically cleared by Release Management, patches should land on mozilla-central prior to being uplifted elsewhere.<br />
* Patches should be uplifted from the most-recent version to the oldest (i.e. Aurora -> Beta -> etc or v2.2 -> v2.1 -> etc). This will help minimize rebasing pain.<br />
* To avoid conflicts, patches should be transplanted from oldest to newest. The search queries below default to sorting in the order the bugs were resolved.<br />
** Until bug 1154728 is resolved, note that Bugherder marks bugs in the *opposite* order of which they landed!<br />
* If there is a branch-specific patch attached to the bug, use that. Otherwise, transplant it using the methods shown in the section above.<br />
* Add a=<whoever approved> to the commit message.<br />
* After pushing, mark the bugs and set the appropriate status flags. The Bugherder tool available from the dropdown on the right side of each push on Treeherder can automate this process.<br />
<br />
= Bug Queries =<br />
The [https://bugzilla.mozilla.org/page.cgi?id=release_tracking_report.html Release Tracking Report] has some useful bug queries. However, it has limitations in that it only sees bugs that have a status of "affected", "fixed", or "verified" set. As a result, it will miss approved bugs if no status is set ("---") and will show bugs as still needing uplift if their status is an unexpected value (like "disabled"). As a result, a combination of this report and the queries below is recommended to avoid missing bugs.<br />
<br />
== B2G ==<br />
Bug queries are on the [https://wiki.mozilla.org/Release_Management/B2G_Landing#Automatic_Branch_Uplifts B2G Landing] page.<br />
<br />
== ESR ==<br />
The ESR intermittent queries are *very* useful for looking at recently-fixed intermittent failure bugs and ensuring that status flags are set for all applicable releases. The [https://wiki.mozilla.org/RapidRelease/Calendar Release Calendar] can help determine in which release an intermittent first appeared (in addition to looking at Treeherderbot comments in the bug).<br />
<br />
<b>ESR45</b><br />
<br />
[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;field0-0-0=flagtypes.name;type0-0-0=equals;value0-0-0=approval-mozilla-esr45%2B;field0-1-0=cf_status_firefox_esr45;type0-1-0=nowordssubstr;value0-1-0=fixed%20verified%20wontfix%20unaffected%20disabled All esr45 approvals not yet uplifted]<br />
<br />
[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved&resolution=FIXED&keywords=intermittent-failure&keywords_type=allwords&field0-0-0=cf_last_resolved&type0-0-0=greaterthaneq&value0-0-0=2015-08-30&field0-1-0=product&type0-1-0=nowordssubstr&value0-1-0=Calendar%20Chat%20MailNews%20QA%20Thunderbird%20Release&field0-2-0=component&type0-2-0=nowordssubstr&value0-2-0=Gaia&field0-3-0=cf_status_firefox_esr45&type0-3-0=nowordssubstr&value0-3-0=fixed%20verified%20wontfix%20unaffected%20disabled Fixed intermittents w/o esr45 {fixed|verified|wontfix|unaffected|disabled}]<br />
<br />
= Best Practicse =<br />
<br />
* Use a unified tree https://wiki.mozilla.org/Sheriffing/How:To:SheriffingFromUnifiedRepos can help you with that<br />
* Use the queries from release_tracking_report to find Bugs to uplift as example<br />
as example "show where approval-mozilla-aurora was changed to approval + between - use custom dates <br />
set the current status of the current aurora version as unfixed like status mozilla-51 not fixed<br />
* Use the Resulting Bugs to uplift <br />
<br />
* As example for a aurora uplift<br />
Pull and update to prepare for the uplifts:<br />
hg pull central<br />
hg pull aurora<br />
hg up aurora<br />
<br />
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:<br />
hg graft --edit -r <revision><br />
<br />
Repeat the previous step as needed for all uplifts as needed. Verify the outgoing changes and push:<br />
hg out -r . aurora<br />
hg push -r . aurora</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Uplift-Sim&diff=1149364Sheriffing/Uplift-Sim2016-09-27T08:14:20Z<p>Tomcat: </p>
<hr />
<div>In order to prevent long Tree-Closures after Release Merge Day, Sheriffs are now doing regular simulations of Code Merges from like Trunk -> Aurora, Aurora -> Beta and Trunk -> Beta<br />
<br />
The steps how to do this Simulations are documented here :<br />
<br />
<br />
* [[Sheriffing/Uplift-Sim/Bump-Trunk|Bump Version Numbers on trunk]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora|Trunk-> Aurora]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora-Nightly|Simulate use Aurora update channel like Aurora nightlies]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Beta|Trunk to Beta]]<br />
* [[Sheriffing/Uplift-Sim//Beta-Release|Use Beta update channel like Beta release builds ]]<br />
* [[Sheriffing/Uplift-Sim/Aurora-Beta|Aurora-Beta]]<br />
<br />
Also configs are in https://bugzilla.mozilla.org/show_bug.cgi?id=1280663<br />
<br />
Results for the Try runs are here :<br />
<br />
{| class="wikitable"<br />
|-<br />
! Date !! Bump Trunk Version !! Trunk Aurora !! Trunk Aurora Nightly !! Trunk to Beta !! Beta-Beta Release Channel !! Aurora-Beta<br />
|-<br />
| 23-Jun-2016 || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=75e7855c3fdd Try Results] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=f1e9009d0405 Try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=647fdd5d6b4f Try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=a70f533f790d try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=a984be3f9889 try results] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=30b58e394d05 Try Result] || <br />
|-<br />
| 6-July-2016 || https://treeherder.mozilla.org/#/jobs?repo=try&revision=7c27828af290 || https://treeherder.mozilla.org/#/jobs?repo=try&revision=d940fbdad048 || https://treeherder.mozilla.org/#/jobs?repo=try&revision=f9b5722bd632 || https://treeherder.mozilla.org/#/jobs?repo=try&revision=45b2aa391354 || https://treeherder.mozilla.org/#/jobs?repo=try&revision=b588bac13056 || https://treeherder.mozilla.org/#/jobs?repo=try&revision=abc0c7b611b7 || <br />
|-<br />
| 23 Sept || - || https://treeherder.mozilla.org/#/jobs?repo=try&revision=1ed628b7783966e2ad643dbc6bb7706820705fb2 || https://treeherder.mozilla.org/#/jobs?repo=try&revision=ba109ca7c3cb145e6c605d7d78620ba7d08fcf67 || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|}</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Backouts&diff=1142644Sheriffing/How To/Backouts2016-08-04T11:15:26Z<p>Tomcat: </p>
<hr />
<div>When a patch is landed that causes build or test failures, it must be backed out to restore the tree to a passing state again. This page documents the procedure for performing backouts both for Gecko changes and Gaia.<br />
<br />
= Gecko Backouts =<br />
== Prerequisites ==<br />
* Install the qbackout extension from https://hg.mozilla.org/hgcustom/version-control-tools/file/default/hgext/qbackout<br />
* Instructions: https://hg.mozilla.org/hgcustom/version-control-tools/file/default/hgext/qbackout/README<br />
<br />
== Usage ==<br />
=== Backout of a single changeset===<br />
hg qbackout -e -r 123456789abc<br />
Where -r is the specific revision to be backed out. The -e option opens an editor to edit the commit message prior to committing. This is useful for adding DONTBUILD, CLOSED TREE, etc before pushing.<br />
<br />
=== Backout of multiple consecutive changesets ===<br />
hg qbackout -e -s -r 123456789abc:cba987654321<br />
Where the -r is now specifying a range of commits (from 123456789abc to cba987654321). The -s option commits the backouts as a single commit. Otherwise, each changeset in the range will be backed out as separate commits.<br />
<br />
=== Backout of multiple non-consecutive changesets ===<br />
hg qbackout -e -s -r 123456789abc+cba987654321<br />
Useful when there are commits in between the ones that need backing out.<br />
<br />
=== Backout of a combination of consecutive and non-consecutive changesets ===<br />
hg qbackout -e -s -r 123456789abc:cba987654321+xyz456789123<br />
Useful when a follow-up patch needs backing out in addition to the main one (i.e. someone had a follow-up bustage fix push) or an additional commit conflicts with the backout and needs backing out as well.<br />
<br />
== Pushing ==<br />
hg qfinish -a<br />
hg push<br />
Finalizes the patch for pushing to the remote repo.<br />
<br />
=== What Ifs ===<br />
* If the remote repo has additional changesets (i.e. a push race), hg pull --rebase will pull the new changesets and rebase the local changes on top of them.<br />
** This requires the [http://mercurial.selenic.com/wiki/RebaseExtension rebase] extension to be enabled in .hgrc<br />
* If the commit message needs to be modifying after qfinish (i.e. forgotten CLOSED TREE), hg commit --amend will open the backout in an editor for modification.<br />
<br />
= Gaia Backouts =<br />
If the changeset is not part of a merge (i.e. pushed directly instead instead of a merged Pull Request):<br />
git revert 12345ab<br />
<br />
If the changeset is a merged Pull Request:<br />
git revert -m 1 12345ab<br />
<br />
Use |git push| once finished. Git also supports |pull --rebase| and |commit --amend| with the same usage as given above for Mercurial.<br />
<br />
For reverting multiple git commits at the same time, see [http://stackoverflow.com/questions/1463340/revert-multiple-git-commits this StackOverflow] post.<br />
<br />
= Best Practices and Communication =<br />
<br />
Based on Feedback from the Sheriff Survey, when you have to do a backout some best practice<br />
<br />
* Ping the Developer in IRC if possible and when the developer is around, this gives the developer a chance to fix the problem and so avoid a backout. Some of the sheriffs use a 5 minute rule for the waiting of a response of the developer<br />
* Set Need-info! This is very important! Developers get a lot of bugmail and so a backout comment can be missed - please make sure that you set a need-info to the developer in the bug when doing a backout<br />
* Make sure that the failures that lead to the backout are stared in treeherder - this helps a lot also the following sheriffs.</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Backouts&diff=1142643Sheriffing/How To/Backouts2016-08-04T11:14:42Z<p>Tomcat: /* Best Practices */</p>
<hr />
<div>When a patch is landed that causes build or test failures, it must be backed out to restore the tree to a passing state again. This page documents the procedure for performing backouts both for Gecko changes and Gaia.<br />
<br />
= Gecko Backouts =<br />
== Prerequisites ==<br />
* Install the qbackout extension from https://hg.mozilla.org/hgcustom/version-control-tools/file/default/hgext/qbackout<br />
* Instructions: https://hg.mozilla.org/hgcustom/version-control-tools/file/default/hgext/qbackout/README<br />
<br />
== Usage ==<br />
=== Backout of a single changeset===<br />
hg qbackout -e -r 123456789abc<br />
Where -r is the specific revision to be backed out. The -e option opens an editor to edit the commit message prior to committing. This is useful for adding DONTBUILD, CLOSED TREE, etc before pushing.<br />
<br />
=== Backout of multiple consecutive changesets ===<br />
hg qbackout -e -s -r 123456789abc:cba987654321<br />
Where the -r is now specifying a range of commits (from 123456789abc to cba987654321). The -s option commits the backouts as a single commit. Otherwise, each changeset in the range will be backed out as separate commits.<br />
<br />
=== Backout of multiple non-consecutive changesets ===<br />
hg qbackout -e -s -r 123456789abc+cba987654321<br />
Useful when there are commits in between the ones that need backing out.<br />
<br />
=== Backout of a combination of consecutive and non-consecutive changesets ===<br />
hg qbackout -e -s -r 123456789abc:cba987654321+xyz456789123<br />
Useful when a follow-up patch needs backing out in addition to the main one (i.e. someone had a follow-up bustage fix push) or an additional commit conflicts with the backout and needs backing out as well.<br />
<br />
== Pushing ==<br />
hg qfinish -a<br />
hg push<br />
Finalizes the patch for pushing to the remote repo.<br />
<br />
=== What Ifs ===<br />
* If the remote repo has additional changesets (i.e. a push race), hg pull --rebase will pull the new changesets and rebase the local changes on top of them.<br />
** This requires the [http://mercurial.selenic.com/wiki/RebaseExtension rebase] extension to be enabled in .hgrc<br />
* If the commit message needs to be modifying after qfinish (i.e. forgotten CLOSED TREE), hg commit --amend will open the backout in an editor for modification.<br />
<br />
= Gaia Backouts =<br />
If the changeset is not part of a merge (i.e. pushed directly instead instead of a merged Pull Request):<br />
git revert 12345ab<br />
<br />
If the changeset is a merged Pull Request:<br />
git revert -m 1 12345ab<br />
<br />
Use |git push| once finished. Git also supports |pull --rebase| and |commit --amend| with the same usage as given above for Mercurial.<br />
<br />
For reverting multiple git commits at the same time, see [http://stackoverflow.com/questions/1463340/revert-multiple-git-commits this StackOverflow] post.<br />
<br />
== Best Practices and Communication ==<br />
<br />
Based on Feedback from the Sheriff Survey, when you have to do a backout some best practice<br />
<br />
* Ping the Developer in IRC if possible and when the developer is around, this gives the developer a chance to fix the problem and so avoid a backout. Some of the sheriffs use a 5 minute rule for the waiting of a response of the developer<br />
* Set Need-info! This is very important! Developers get a lot of bugmail and so a backout comment can be missed - please make sure that you set a need-info to the developer in the bug when doing a backout<br />
* Make sure that the failures that lead to the backout are stared in treeherder - this helps a lot also the following sheriffs.</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How_To/Backouts&diff=1142638Sheriffing/How To/Backouts2016-08-04T09:11:25Z<p>Tomcat: </p>
<hr />
<div>When a patch is landed that causes build or test failures, it must be backed out to restore the tree to a passing state again. This page documents the procedure for performing backouts both for Gecko changes and Gaia.<br />
<br />
= Gecko Backouts =<br />
== Prerequisites ==<br />
* Install the qbackout extension from https://hg.mozilla.org/hgcustom/version-control-tools/file/default/hgext/qbackout<br />
* Instructions: https://hg.mozilla.org/hgcustom/version-control-tools/file/default/hgext/qbackout/README<br />
<br />
== Usage ==<br />
=== Backout of a single changeset===<br />
hg qbackout -e -r 123456789abc<br />
Where -r is the specific revision to be backed out. The -e option opens an editor to edit the commit message prior to committing. This is useful for adding DONTBUILD, CLOSED TREE, etc before pushing.<br />
<br />
=== Backout of multiple consecutive changesets ===<br />
hg qbackout -e -s -r 123456789abc:cba987654321<br />
Where the -r is now specifying a range of commits (from 123456789abc to cba987654321). The -s option commits the backouts as a single commit. Otherwise, each changeset in the range will be backed out as separate commits.<br />
<br />
=== Backout of multiple non-consecutive changesets ===<br />
hg qbackout -e -s -r 123456789abc+cba987654321<br />
Useful when there are commits in between the ones that need backing out.<br />
<br />
=== Backout of a combination of consecutive and non-consecutive changesets ===<br />
hg qbackout -e -s -r 123456789abc:cba987654321+xyz456789123<br />
Useful when a follow-up patch needs backing out in addition to the main one (i.e. someone had a follow-up bustage fix push) or an additional commit conflicts with the backout and needs backing out as well.<br />
<br />
== Pushing ==<br />
hg qfinish -a<br />
hg push<br />
Finalizes the patch for pushing to the remote repo.<br />
<br />
=== What Ifs ===<br />
* If the remote repo has additional changesets (i.e. a push race), hg pull --rebase will pull the new changesets and rebase the local changes on top of them.<br />
** This requires the [http://mercurial.selenic.com/wiki/RebaseExtension rebase] extension to be enabled in .hgrc<br />
* If the commit message needs to be modifying after qfinish (i.e. forgotten CLOSED TREE), hg commit --amend will open the backout in an editor for modification.<br />
<br />
= Gaia Backouts =<br />
If the changeset is not part of a merge (i.e. pushed directly instead instead of a merged Pull Request):<br />
git revert 12345ab<br />
<br />
If the changeset is a merged Pull Request:<br />
git revert -m 1 12345ab<br />
<br />
Use |git push| once finished. Git also supports |pull --rebase| and |commit --amend| with the same usage as given above for Mercurial.<br />
<br />
For reverting multiple git commits at the same time, see [http://stackoverflow.com/questions/1463340/revert-multiple-git-commits this StackOverflow] post.<br />
<br />
=== Best Practices ===<br />
<br />
Based on Feedback from the Sheriff Survey, when you have to do a backout some best practice<br />
<br />
* Ping the Developer in IRC if possible and when the developer is around, this gives the developer a chance to fix the problem and so avoid a backout. Some of the sheriffs use a 5 minute rule for the waiting of a response of the developer<br />
* Set Need-info! This is very important! Developers get a lot of bugmail and so a backout comment can be missed - please make sure that you set a need-info to the developer in the bug when doing a backout<br />
* Make sure that the failures that lead to the backout are stared in treeherder - this helps a lot also the following sheriffs.</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing&diff=1140503Sheriffing2016-07-21T03:43:06Z<p>Tomcat: /* Meet the Sheriffs */</p>
<hr />
<div>= The Tree Sheriffs =<br />
<br />
When we moved to the "inbound" model of tree management, the Tree Sheriffs became a crucial part of our engineering infrastructure. The primary responsibility of the Sheriffs is and will always be to aid developers to easily, quickly, and seamlessly land their code in the proper location(s) and ensure that code does not break our automated tests. In the service of this objective, the Sheriffs work closely with the larger engineering organization to create and enforce landing policies that increase productivity while maintaining an efficient and robust automated testing system. Beyond the policy role, they have also become shepherds of automation quality by monitoring intermittent failures, performing uplifts and merges, and identifying poorly performing automation machines. This role has proven successful, and so a formal module for the Tree Sheriffs in the larger context of the Activities Module was created: [[Modules/Activities#Tree_Sheriffs]].<br />
<br />
The living document of Sheriff roles and responsibilities will be kept up to date on this wiki page and will certainly change over time as our organization and our automation continues to expand. But this module and this document will help give the sheriffs a platform to work from for future changes.<br />
<br />
== Meet the Sheriffs ==<br />
The owners & peers of the Tree Sheriffs module can be found on the [[Modules/Activities#Tree_Sheriffs|module page]], however for day to day sheriffduty coverage look for the following people in #developers (the on-duty sheriff will typically have |sheriffduty appended to their IRC nick):<br />
* UTC+5:30: Nigel Babu [:nigelb]<br />
* UTC+1: Carsten Book [:Tomcat]<br />
* UTC+1: Ms2ger (who denies being a sheriff unless it suits him)<br />
* UTC-4: Ryan VanderMeulen [:RyanVM] (not actively sheriffing, but available to help in an emergency)<br />
* UTC-8: Wes Kocher [:KWierso]<br />
* UTC-8: Phil Ringnalda [:philor]<br />
* UTC+8: Iris Hsiao [:ihsiao]<br />
<br />
If you want to know more about us see our [[Auto-tools/The Sheriffs|Teampage]]<br />
<br />
For more info on what's happening at the moment, see the on-duty notes:<br />
https://public.etherpad-mozilla.org/p/sheriffing-notes<br />
<br />
We're always looking for more people to join the team and help out - just drop us a message!<br />
<br />
= Links =<br />
* [https://developer.mozilla.org/en-US/docs/Developer_Guide/Committing_Rules_and_Responsibilities Committing rules and responsibilities]<br />
* [[Tree Rules]]<br />
* Notes for sheriffs handover/current issues: https://public.etherpad-mozilla.org/p/sheriffing-notes<br />
* [[Sheriffing/How:To|How-to guides]]<br />
* [[Sheriffing/How:To:Recommended_Try_Practices]]<br />
* [[Sheriffing/Test_Disabling_Policy]]<br />
* [[Sheriffing/Job Visibility Policy]]<br />
* [[Sheriffing/Deciding To Close A Tree]]<br />
* [[Auto-tools/Projects/Treeherder|Treeherder]] (replacement for TBPL)<br />
* Need cleanup:<br />
** https://developer.mozilla.org/en-US/docs/Tinderbox<br />
** https://developer.mozilla.org/en-US/docs/Test_log_format<br />
** https://etherpad.mozilla.org/SheriffOnboarding</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Outage_Notice&diff=1140105Sheriffing/Outage Notice2016-07-18T15:22:09Z<p>Tomcat: </p>
<hr />
<div>=== DRAFT ===<br />
<br />
Note this is a draft and more concept idea - so work in progress<br />
<br />
=== Introduction ===<br />
<br />
Development Work at Mozilla depend a lot on open Trees like Mozilla-Inbound, Fx-Team and even Mozilla-Try. Sheriffs maintain and control the Status of the Trees and Close Trees if needed. <br />
<br />
Mostly this Tree-Closures are due failing Code (like Build Bustages, Test failures) and are this Tree Closures are normally fixed very temporary. However we might have cases where we have longer Tree-Closures due to Infra Related Problems that are UN-planned and need deeper investigations by Teams like IT,Releng, Taskcluster etc<br />
<br />
For this cases we might need notifications to Developers to :<br />
<br />
<br />
* Avoid frustrations when people want to push to try and notice its not possible<br />
* Pending/Running Testruns (especially try) fails to whatever unrelated reasons and cause a Developer to spend time on issues that are not caused by her/his changes<br />
* Reduce hammering on Sheriffs why a tree is closed and whats the eta etc<br />
<br />
=== Steps to-do from the onduty Sheriff ===<br />
<br />
1.) make clear that there is a outage and who is the current Sheriff with changing the topic of the #developers channel on IRC. Please add also the tracking bug and a possible eta time into the topic of #developers.<br />
<br />
example:<br />
Onduty-Sheriff: Tomcat - All Tree Closure - Database issue Bug 1234567 - no eta yet<br />
<br />
2.) Post a short mail to the mozilla.dev.platform and dev-fxos <dev-fxos@lists.mozilla.org> newsgroup like https://groups.google.com/forum/#!topic/mozilla.dev.platform/Kzd1es4KiYA - also like here the next sheriff could if the issue is fixed sent a all clear information.</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Outage_Notice&diff=1140104Sheriffing/Outage Notice2016-07-18T15:21:00Z<p>Tomcat: </p>
<hr />
<div>=== DRAFT ===<br />
<br />
Note this is a draft and more concept idea - so work in progress<br />
<br />
=== Introduction ===<br />
<br />
Development Work at Mozilla depend a lot on open Trees like Mozilla-Inbound, Fx-Team and even Mozilla-Try. Sheriffs maintain and control the Status of the Trees and Close Trees if needed. <br />
<br />
Mostly this Tree-Closures are due failing Code (like Build Bustages, Test failures) and are this Tree Closures are normally fixed very temporary. However we might have cases where we have longer Tree-Closures due to Infra Related Problems that are UN-planned and need deeper investigations by Teams like IT,Releng, Taskcluster etc<br />
<br />
For this cases we might need notifications to Developers to :<br />
<br />
-> Avoid frustrations when people want to push to try and notice its not possible<br />
-> Pending/Running Testruns (especially try) fails to whatever unrelated reasons and cause a Developer to spend time on issues that are not caused by her/his changes<br />
-> Reduce hammering on Sheriffs why a tree is closed and whats the eta etc<br />
<br />
=== Steps to-do from the onduty Sheriff ==<br />
<br />
1.) make clear that there is a outage and who is the current Sheriff with changing the topic of the #developers channel on IRC. Please add also the tracking bug and a possible eta time into the topic of #developers.<br />
<br />
example:<br />
Onduty-Sheriff: Tomcat - All Tree Closure - Database issue Bug 1234567 - no eta yet<br />
<br />
2.) Post a short mail to the mozilla.dev.platform and dev-fxos <dev-fxos@lists.mozilla.org> newsgroup like https://groups.google.com/forum/#!topic/mozilla.dev.platform/Kzd1es4KiYA - also like here the next sheriff could if the issue is fixed sent a all clear information.</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Uplift-Sim&diff=1138843Sheriffing/Uplift-Sim2016-07-06T14:58:49Z<p>Tomcat: </p>
<hr />
<div>In order to prevent long Tree-Closures after Release Merge Day, Sheriffs are now doing regular simulations of Code Merges from like Trunk -> Aurora, Aurora -> Beta and Trunk -> Beta<br />
<br />
The steps how to do this Simulations are documented here :<br />
<br />
<br />
* [[Sheriffing/Uplift-Sim/Bump-Trunk|Bump Version Numbers on trunk]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora|Trunk-> Aurora]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora-Nightly|Simulate use Aurora update channel like Aurora nightlies]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Beta|Trunk to Beta]]<br />
* [[Sheriffing/Uplift-Sim//Beta-Release|Use Beta update channel like Beta release builds ]]<br />
* [[Sheriffing/Uplift-Sim/Aurora-Beta|Aurora-Beta]]<br />
<br />
Also configs are in https://bugzilla.mozilla.org/show_bug.cgi?id=1280663<br />
<br />
Results for the Try runs are here :<br />
<br />
{| class="wikitable"<br />
|-<br />
! Date !! Bump Trunk Version !! Trunk Aurora !! Trunk Aurora Nightly !! Trunk to Beta !! Beta-Beta Release Channel !! Aurora-Beta<br />
|-<br />
| 23-Jun-2016 || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=75e7855c3fdd Try Results] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=f1e9009d0405 Try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=647fdd5d6b4f Try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=a70f533f790d try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=a984be3f9889 try results] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=30b58e394d05 Try Result] || <br />
|-<br />
| 6-July-2016 || https://treeherder.mozilla.org/#/jobs?repo=try&revision=7c27828af290 || https://treeherder.mozilla.org/#/jobs?repo=try&revision=d940fbdad048 || https://treeherder.mozilla.org/#/jobs?repo=try&revision=f9b5722bd632 || https://treeherder.mozilla.org/#/jobs?repo=try&revision=45b2aa391354 || https://treeherder.mozilla.org/#/jobs?repo=try&revision=b588bac13056 || https://treeherder.mozilla.org/#/jobs?repo=try&revision=abc0c7b611b7 || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|}</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Backout-setup&diff=1138803Sheriffing/Backout-setup2016-07-06T07:12:42Z<p>Tomcat: Created page with "In order to do backout's and checkins some setup is needed 1.) make sure you have mercurial installed 2.) Clone Repos that we as sheriff maintain like mozilla-central, mozil..."</p>
<hr />
<div>In order to do backout's and checkins some setup is needed<br />
<br />
1.) make sure you have mercurial installed <br />
2.) Clone Repos that we as sheriff maintain like mozilla-central, mozilla-inbound, fx-team and autoland <br />
3.) customize your .hg/hgrc of that trees as example my one for mozilla-inbound looks :<br />
<br />
[paths]<br />
default = http://hg.mozilla.org/integration/mozilla-inbound<br />
default-push = ssh://hg.mozilla.org/integration/mozilla-inbound<br />
[ui]<br />
username = Carsten "Tomcat" Book <cbook@mozilla.com><br />
merge = internal:merge<br />
[extensions]<br />
qbackout = /sheriffs/trees/version-control-tools/hgext/qbackout<br />
histedit =<br />
progress =<br />
rebase =<br />
mq =<br />
qimportbz = /sheriffs/trees/version-control-tools/hgext/qimportbz<br />
transplant =<br />
[alias]<br />
rbimport = !hg transplant -e -s https://reviewboard-hg.mozilla.org/gecko -b $1<br />
<br />
The whole backout is simple: <br />
<br />
As example a developer asks you to backout changeset ab1234 so the command for the backout would be <br />
<br />
hg qbackout -r ab1234 && hg qrefresh -e <br />
<br />
The hg qbackout -r <revision> should contain the revision you will backout. The hg qrefresh -e command allows you to edit the commit message for the backout, like why you backout something (example for bustage). <br />
<br />
Backout multiple changsets ? <br />
<br />
As example you need to backout a push that had multiple changesets/parts, the command would be <br />
<br />
hg qbackout -r firstcset -r 2ndcset && hg qrefresh -e</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/How:To:Autoland&diff=1138531Sheriffing/How:To:Autoland2016-07-04T04:17:41Z<p>Tomcat: Created page with "The Autoland Repo is part of a future plan to get rid of merge commits: https://bugzilla.mozilla.org/show_bug.cgi?id=1266863 = Where to find autoland = https://hg.mozilla.o..."</p>
<hr />
<div>The Autoland Repo is part of a future plan to get rid of merge commits: <br />
https://bugzilla.mozilla.org/show_bug.cgi?id=1266863<br />
<br />
= Where to find autoland =<br />
<br />
https://hg.mozilla.org/integration/autoland<br />
<br />
Currently all mozreview autoland commits go to autoland<br />
<br />
= Handling by Sheriffs = <br />
<br />
There are future plans to rebase autoland to m-c and to get rid of merges and backout commits etc. There will be tools but '''as of July 4th 2016 current state for sheriffs is:'''<br />
<br />
* Autoland is handled as we mozilla-inbound / fx-team with means<br />
** Backouts will happen when regressions occur<br />
** Staring as usual<br />
** Is part of merges/updates from/to m-c (since we prefer rebase autoland to m-c please try to update auto-land to m-c first before fx-team and mozilla-inbound<br />
<br />
= Handling conflicts with especially mozilla-inbound =<br />
<br />
Code might be changed in parallel in mozilla-inbound & autoland and this might result in merge conflicts.<br />
<br />
Here is some concept how to handle such situations:<br />
<br />
# back out conflicting commit(s) from inbound <br />
# merge the commit before the backed out commit from inbound to central (this ensures that at least some commits from inbound are merged into central)<br />
# merge central into inbound (on top of the backout commits you just landed)<br />
<br />
Just be sure that when you do step 2 that there no other regressions etc that you might merge into central. Otherwise you have to wait till you have a mergeable changeset (with pgo run etc) from you commit from step 1.<br />
<br />
= Need help =<br />
<br />
If you have questions about autoland please ping: gps, Tomcat, Kwierso</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Uplift-Sim&diff=1137434Sheriffing/Uplift-Sim2016-06-23T11:50:32Z<p>Tomcat: </p>
<hr />
<div>In order to prevent long Tree-Closures after Release Merge Day, Sheriffs are now doing regular simulations of Code Merges from like Trunk -> Aurora, Aurora -> Beta and Trunk -> Beta<br />
<br />
The steps how to do this Simulations are documented here :<br />
<br />
<br />
* [[Sheriffing/Uplift-Sim/Bump-Trunk|Bump Version Numbers on trunk]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora|Trunk-> Aurora]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora-Nightly|Simulate use Aurora update channel like Aurora nightlies]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Beta|Trunk to Beta]]<br />
* [[Sheriffing/Uplift-Sim//Beta-Release|Use Beta update channel like Beta release builds ]]<br />
* [[Sheriffing/Uplift-Sim/Aurora-Beta|Aurora-Beta]]<br />
<br />
Also configs are in https://bugzilla.mozilla.org/show_bug.cgi?id=1280663<br />
<br />
Results for the Try runs are here :<br />
<br />
{| class="wikitable"<br />
|-<br />
! Date !! Bump Trunk Version !! Trunk Aurora !! Trunk Aurora Nightly !! Trunk to Beta !! Beta-Beta Release Channel !! Aurora-Beta<br />
|-<br />
| 23-Jun-2016 || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=75e7855c3fdd Try Results] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=f1e9009d0405 Try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=647fdd5d6b4f Try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=a70f533f790d try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=a984be3f9889 try results] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=30b58e394d05 Try Result] || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|}</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Uplift-Sim&diff=1137433Sheriffing/Uplift-Sim2016-06-23T11:49:41Z<p>Tomcat: </p>
<hr />
<div>In order to prevent long Tree-Closures after Release Merge Day, Sheriffs are now doing regular simulations of Code Merges from like Trunk -> Aurora, Aurora -> Beta and Trunk -> Beta<br />
<br />
The steps how to do this Simulations are documented here :<br />
<br />
<br />
* [[Sheriffing/Uplift-Sim/Bump-Trunk|Bump Version Numbers on trunk]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora|Trunk-> Aurora]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora-Nightly|Simulate use Aurora update channel like Aurora nightlies]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Beta|Trunk to Beta]]<br />
* [[Sheriffing/Uplift-Sim//Beta-Release|Use Beta update channel like Beta release builds ]]<br />
* [[Sheriffing/Uplift-Sim/Aurora-Beta|Aurora-Beta]]<br />
<br />
<br />
Results for the Try runs are here :<br />
<br />
{| class="wikitable"<br />
|-<br />
! Date !! Bump Trunk Version !! Trunk Aurora !! Trunk Aurora Nightly !! Trunk to Beta !! Beta-Beta Release Channel !! Aurora-Beta<br />
|-<br />
| 23-Jun-2016 || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=75e7855c3fdd Try Results] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=f1e9009d0405 Try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=647fdd5d6b4f Try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=a70f533f790d try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=a984be3f9889 try results] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=30b58e394d05 Try Result] || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|}</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Uplift-Sim&diff=1137432Sheriffing/Uplift-Sim2016-06-23T11:49:00Z<p>Tomcat: </p>
<hr />
<div>In order to prevent long Tree-Closures after Release Merge Day, Sheriffs are now doing regular simulations of Code Merges from like Trunk -> Aurora, Aurora -> Beta and Trunk -> Beta<br />
<br />
The steps how to do this Simulations are documented here :<br />
<br />
<br />
* [[Sheriffing/Uplift-Sim/Bump-Trunk|Bump Version Numbers on trunk]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora|Trunk-> Aurora]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora-Nightly|Simulate use Aurora update channel like Aurora nightlies]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Beta|Trunk to Beta]]<br />
* [[Sheriffing/Uplift-Sim//Beta-Release|Use Beta update channel like Beta release builds ]]<br />
* [[Sheriffing/Uplift-Sim/Aurora-Beta|Aurora-Beta]]<br />
<br />
<br />
Results for the Try runs are here :<br />
<br />
{| class="wikitable"<br />
|-<br />
! Date !! Bump Trunk Version !! Trunk Aurora !! Trunk Aurora Nightly !! Trunk to Beta !! Beta-Beta Release Channel !! Aurora-Beta<br />
|-<br />
| 23-Jun-2016 || [http://%20https://treeherder.mozilla.org/#/jobs?repo=try&revision=75e7855c3fdd Try Results] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=f1e9009d0405 Try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=647fdd5d6b4f Try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=a70f533f790d try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=a984be3f9889 try results] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=30b58e394d05 Try Result] || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|}</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Uplift-Sim&diff=1137431Sheriffing/Uplift-Sim2016-06-23T11:48:19Z<p>Tomcat: </p>
<hr />
<div>In order to prevent long Tree-Closures after Release Merge Day, Sheriffs are now doing regular simulations of Code Merges from like Trunk -> Aurora, Aurora -> Beta and Trunk -> Beta<br />
<br />
The steps how to do this Simulations are documented here :<br />
<br />
<br />
* [[Sheriffing/Uplift-Sim/Bump-Trunk|Bump Version Numbers on trunk]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora|Trunk-> Aurora]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora-Nightly|Simulate use Aurora update channel like Aurora nightlies]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Beta|Trunk to Beta]]<br />
* [[Sheriffing/Uplift-Sim//Beta-Release|Use Beta update channel like Beta release builds ]]<br />
* [[Sheriffing/Uplift-Sim/Aurora-Beta|Aurora-Beta]]<br />
<br />
<br />
Results for the Try runs are here :<br />
<br />
{| class="wikitable"<br />
|-<br />
! Date !! Bump Trunk Version !! Trunk Aurora !! Trunk Aurora Nightly !! Trunk to Beta !! Beta-Beta Release Channel !! Aurora-Beta<br />
|-<br />
| 26-Jul-2016 || [http://%20https://treeherder.mozilla.org/#/jobs?repo=try&revision=75e7855c3fdd Try Results] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=f1e9009d0405 Try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=647fdd5d6b4f Try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=a70f533f790d try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=a984be3f9889 try results] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=30b58e394d05 Try Result] || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|}</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Uplift-Sim&diff=1137430Sheriffing/Uplift-Sim2016-06-23T11:36:35Z<p>Tomcat: </p>
<hr />
<div>In order to prevent long Tree-Closures after Release Merge Day, Sheriffs are now doing regular simulations of Code Merges from like Trunk -> Aurora, Aurora -> Beta and Trunk -> Beta<br />
<br />
The steps how to do this Simulations are documented here :<br />
<br />
<br />
* [[Sheriffing/Uplift-Sim/Bump-Trunk|Bump Version Numbers on trunk]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora|Trunk-> Aurora]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora-Nightly|Simulate use Aurora update channel like Aurora nightlies]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Beta|Trunk to Beta]]<br />
* [[Sheriffing/Uplift-Sim/Beta-Release]]<br />
* [[Sheriffing/Uplift-Sim/Aurora-Beta|Aurora-Beta]]<br />
<br />
<br />
Results for the Try runs are here :<br />
<br />
{| class="wikitable"<br />
|-<br />
! Date !! Bump Trunk Version !! Trunk Aurora !! Trunk Aurora Nightly !! Trunk to Beta !! Beta-Release !! Aurora-Beta<br />
|-<br />
| 26-Jul-2016 || [http://%20https://treeherder.mozilla.org/#/jobs?repo=try&revision=75e7855c3fdd Try Results] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=f1e9009d0405 Try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=647fdd5d6b4f Try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=a70f533f790d try result] || Example || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=30b58e394d05 Try Result] || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|}</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Uplift-Sim&diff=1137429Sheriffing/Uplift-Sim2016-06-23T11:28:47Z<p>Tomcat: </p>
<hr />
<div>In order to prevent long Tree-Closures after Release Merge Day, Sheriffs are now doing regular simulations of Code Merges from like Trunk -> Aurora, Aurora -> Beta and Trunk -> Beta<br />
<br />
The steps how to do this Simulations are documented here :<br />
<br />
<br />
* [[Sheriffing/Uplift-Sim/Bump-Trunk|Bump Version Numbers on trunk]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora|Trunk-> Aurora]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora-Nightly|Simulate use Aurora update channel like Aurora nightlies]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Beta|Trunk to Beta]]<br />
* [[Sheriffing/Uplift-Sim/Beta-Release]]<br />
* [[Sheriffing/Uplift-Sim/Aurora-Beta|Aurora-Beta]]<br />
<br />
<br />
Results for the Try runs are here :<br />
<br />
{| class="wikitable"<br />
|-<br />
! Date !! Bump Trunk Version !! Trunk Aurora !! Trunk Aurora Nightly !! Trunk to Beta !! Beta-Release !! Aurora-Beta<br />
|-<br />
| 26-Jul-2016 || [http://%20https://treeherder.mozilla.org/#/jobs?repo=try&revision=75e7855c3fdd Try Results] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=f1e9009d0405 Try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=647fdd5d6b4f Try result] || [https://treeherder.mozilla.org/#/jobs?repo=try&revision=a70f533f790d try result] || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|}</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Uplift-Sim&diff=1137428Sheriffing/Uplift-Sim2016-06-23T11:20:09Z<p>Tomcat: </p>
<hr />
<div>In order to prevent long Tree-Closures after Release Merge Day, Sheriffs are now doing regular simulations of Code Merges from like Trunk -> Aurora, Aurora -> Beta and Trunk -> Beta<br />
<br />
The steps how to do this Simulations are documented here :<br />
<br />
<br />
* [[Sheriffing/Uplift-Sim/Bump-Trunk|Bump Version Numbers on trunk]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora|Trunk-> Aurora]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora-Nightly|Simulate use Aurora update channel like Aurora nightlies]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Beta|Trunk to Beta]]<br />
* [[Sheriffing/Uplift-Sim/Beta-Release]]<br />
* [[Sheriffing/Uplift-Sim/Aurora-Beta|Aurora-Beta]]<br />
<br />
<br />
Results for the Try runs are here :<br />
<br />
{| class="wikitable"<br />
|-<br />
! Date !! Bump Trunk Version !! Trunk Aurora !! Trunk Aurora Nightly !! Trunk to Beta !! Beta-Release !! Aurora-Beta<br />
|-<br />
| 26-Jul-2016 || [http://%20https://treeherder.mozilla.org/#/jobs?repo=try&revision=75e7855c3fdd Try Results] || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|}</div>Tomcathttps://wiki.mozilla.org/index.php?title=Sheriffing/Uplift-Sim&diff=1137123Sheriffing/Uplift-Sim2016-06-17T12:10:15Z<p>Tomcat: </p>
<hr />
<div>In order to prevent long Tree-Closures after Release Merge Day, Sheriffs are now doing regular simulations of Code Merges from like Trunk -> Aurora, Aurora -> Beta and Trunk -> Beta<br />
<br />
The steps how to do this Simulations are documented here :<br />
<br />
<br />
* [[Sheriffing/Uplift-Sim/Bump-Trunk|Bump Version Numbers on trunk]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora|Trunk-> Aurora]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Aurora-Nightly|Simulate use Aurora update channel like Aurora nightlies]]<br />
* [[Sheriffing/Uplift-Sim/Trunk-Beta|Trunk to Beta]]<br />
* [[Sheriffing/Uplift-Sim/Beta-Release]]<br />
* [[Sheriffing/Uplift-Sim/Aurora-Beta|Aurora-Beta]]<br />
<br />
<br />
Results for the Try runs are here :<br />
<br />
{| class="wikitable"<br />
|-<br />
! Date !! Bump Trunk Version !! Trunk Aurora !! Trunk Aurora Nightly !! Trunk to Beta !! Beta-Release !! Aurora-Beta<br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|-<br />
| Example || Example || Example || Example || Example || Example || Example || <br />
|}</div>Tomcat