MozillaWiki - User contributions [en]

ReleaseEngineering/How To/Self Provision a TaskCluster Windows Instance

2019-10-04T21:37:16Z

KWierso: Correct the Template

{{Release Engineering How To|Self Provision a TaskCluster Windows Instance}}

__TOC__

= For generic-worker 10.5.0 onwards =

'''Integration with taskcluster one-click loaner workflow will be done in [https://bugzil.la/1368961 bug 1368961].'''

1) If you are connecting to a hardware worker in our data center (provisionerId: "releng-hardware") such as a MoonShot machine, make sure to
announce in #ci and/or create a bug under [https://bugzilla.mozilla.org/enter_bug.cgi?product=Infrastructure%20%26%20Operations&component=CIDuty CiDuty - Buzilla] announcing the fact that you will take a loaner.

2) Find a the task you want to play with in treeherder, and follow the link to the Taskcluster Task Inspector. 
3) Go to ''Actions -> Edit Task''. 
4) Add <code>rdpInfo</code> to the payload section:

payload:
rdpInfo: 'login-identity/<login-identity>/rdpinfo.txt'

For example:

payload:
rdpInfo: 'login-identity/mozilla-auth0/ad|Mozilla-LDAP|pmoore/rdpinfo.txt'

(check https://tools.taskcluster.net/credentials to see what your login identity is, e.g. you should have the scope <code>assume:login-identity:<login-identity></code>).

4) Check which <code>workerType</code> the task uses from the task definition, and then add the following scope to the list of task scopes:

scopes:
- 'generic-worker:allow-rdp:aws-provisioner-v1/<workerType>'

For example:

scopes:
- 'generic-worker:allow-rdp:aws-provisioner-v1/gecko-t-win7-32'

5) If you will require administrator privileges:

5.1) Ensure you have scope <code>generic-worker:os-group:<provisionerId>/<workerType>/Administrators</code> in https://tools.taskcluster.net/credentials/

If you do not have the scope, request it using a [https://bugzilla.mozilla.org/enter_bug.cgi?product=Taskcluster&component=Service%20Request Service Request] or by asking in <code>#taskcluster</code> IRC channel.

5.2) Add the following to the task payload:

scopes:
- generic-worker:os-group:<provisionerId>/<workerType>/Administrators
payload:
osGroups:
- Administrators

6) Make sure that if your payload mounts any artifacts, that the task ID(s) are included as a list in top level property <code>dependencies</code> ('''not''' under <code>payload</code>)

So if it says

mounts:
- directory: .
content:
taskId: HUqhbXTMTXSXYEM6K2H3wA

Add (at the top level indent)

dependencies:
- HUqhbXTMTXSXYEM6K2H3wA

7) Submit the task. If the task resolves as exception and doesn't run, '''check the task log file'''. It should provide more information about the cause. 
8) When the task successfully starts, go to ''Run Artifacts'' to see the <code>rdpInfo.txt</code> file appear with rdp connection information. 
9) Enter the connection information into your RDP client of choice. 
10) Connect with screen resolution 1280x1024 ! Note, it is '''important''' to use this resolution for gecko tests, since this is the screen size used by the tests, and the screen size cannot change once you have made a connection.

== Performing operations as Administrator ==

Until [https://bugzil.la/1465374 bug 1465374] is resolved this can be a little tricky.

1) Make sure you followed step 5 above! 
2) Open a regular command shell (e.g. ''Start Menu'' -> ''Run'' -> <code>cmd.exe</code>) 
3) From there check which users are in the Administrators group:

C:\Windows\System32>net localgroup Administrators
Alias name Administrators
Comment Administrators have complete and unrestricted access to the computer/domain

Members

-------------------------------------------------------------------------------
Administrator
task_1527672240
The command completed successfully.

4) Check the user you are logged in as is one of the above listed users:

C:\Windows\System32>whoami
i-015fe55bb8553\task_1527672240

5) Open a new UAC elevated command shell:

C:\Windows\System32>powershell.exe Start-Process cmd.exe -Verb runAs

6) This will require you enter Administrative credentials. You will be presented with a prompt similar to this:

[[File:Screen Shot 2018-05-30 at 12.13.51.png|none|Screenshot of dialogue box asking for Administrative credentials]]

Click on ''More choices'' and select the task user, and copy/paste the task password (<code>Ctrl-V</code>).

You should now have a command shell running as Administrator!

== Rerunning tasks after they have completed ==

If you want to rerun a step after the task has completed, there is a script for each command in the task payload. They are named like this:

Z:\task_XXXXXXX\command_000000_wrapper.bat
Z:\task_XXXXXXX\command_000001_wrapper.bat
Z:\task_XXXXXXX\command_000002_wrapper.bat
....

Simply run them by hand to reproduce any of the task steps. If you wish to make changes, feel free to edit them. After the loan expires, the task directory, including all your changes, will be deleted. Therefore make sure to keep track of any changes that need to be put back in the gecko build system.

ReleaseEngineering/TryServer

2019-09-24T18:50:29Z

KWierso: Document the Add New Jobs (Search) option in Treeherder

= Try Server =
The [https://treeherder.mozilla.org/#/jobs?repo=try try server] is an easy way to test a patch without actually checking the patch into the core repository. Your code will go through the same tests as a mozilla-central push, and you'll be able to download builds if you wish.

== Getting access to the Try Server ==
To use the try server, you'll need [http://www.mozilla.org/hacking/commit-access-policy/ Level 1 Commit Access]. You can learn more about Mozilla's commit access policies and start the process of signing up for an account here: [http://www.mozilla.org/hacking/committer/ Becoming a Mozilla Contributor]

After you have level 1 commit access, you'll need to do a bit of setup before you'll be able to push. See [https://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/auth.html this guide] for instructions.

== Configuration ==
Before using try, there is some recommended configuration you should set up. This can be accomplished by running:

$ ./mach vcs-setup

Be sure to at least enable the [http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html firefoxtree extension] and the push-to-try extension. The push-to-try extension is required if you wish to use the |mach try| command (see below). Firefoxtree will give you a handy 'try' alias you can use for pushing, and prevent you from accidentally pushing multiple heads. If for some reason you prefer not to use firefoxtree, you can set the same alias up manually in your hgrc:

[paths]
try = ssh://hg.mozilla.org/try

Note: Never pull the whole try repo. You'll end up with hundreds of heads containing everyone's half baked and broken pushes.

For more information, see [http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/index.html mercurial for mozillians].

== How to push to try ==
There are a few ways to schedule jobs on try.

=== Scheduling jobs with Mach Try ===

The recommended way to [https://firefox-source-docs.mozilla.org/tools/try/index.html interact with try] is via the command line tool |mach try|. Since try can be used for a wide range of use cases, by developers with varying levels of experience, there is no one size fits all solution when it comes to selecting which tasks to run. Therefore |mach try| offers a range of subcommands called "selectors" for a variety of purposes. To see a list of available selectors, run:

$ mach try --help

For deeper information on a given selector, run:

$ mach try <selector> --help

If you don't specify a selector/subcommand to try, it will default to using the `syntax` selector. You can change which selector gets used by default by creating ~/.mozbuild/machrc and adding:

[try]
default=<selector>

See [https://firefox-source-docs.mozilla.org/tools/try/selectors/index.html this documentation] for more information on all the available selectors.

=== Scheduling jobs with Treeherder ===

You can push to try with:

$ ./mach try empty

Once the push succeeds, you can open it in Treeherder and then sign in to schedule jobs manually.

Select the drop-down arrow at the top right of your push, and choose "Add new Jobs". It might take several seconds for the jobs to load ({{bug|1288028}}) :

https://s3.amazonaws.com/media-p.slid.es/uploads/185196/images/2042414/TH_dropdown.png

If it helps, you can use the filter box in the site header to restrict the list of runnable jobs being displayed. Click the job symbols you wish to schedule.

If you select a test job, the required build will automatically be scheduled:

https://s3.amazonaws.com/media-p.slid.es/uploads/185196/images/2042426/TH_with_jobs.png

Finally, click "Trigger New Jobs" near the top right of your push.

NOTE: An action task gets scheduled which will schedule all the tasks you chose.

=== Scheduling jobs with Treeherder (Search) ===

Similar to the above method, there is now an additional way to add jobs to an existing push via Treeherder. Open the push in Treeherder and then choose "Add New Jobs (Search)" from the push's menu:

[[File:Add New Jobs Search.png]]

Treeherder will then fetch the list of runnable jobs in the background, then pop up a dialog window listing those jobs:

[[File:Addnewjobssearchinterface.png]]

At the top of the dialog, there is a search bar. Type part of your desired job name into the search bar and press 'Enter' to filter the list of jobs. (This uses a fuzzy search library, so some minimal typos are allowed). From the filtered list of jobs, select as many of the results as you want (ctrl/shift modifiers work on this list for selecting multiple jobs):

[[File:Filteredaddnewjobssearch.png]]

Then click the green "Add Selected" button to add the selected jobs to the list of jobs to be run (or click the green "Add All" button to add the entire list of jobs currently in view.

Repeat the filter and selection process until you have all of your desired jobs added to the list. You can remove jobs from the list to be run using the red buttons lower on the dialog if you selected them in error:

[[File:Addnewjobssearchselectedjobs.png]]

When you are happy with your selection, click the blue "Trigger (X) Selected Jobs" button at the bottom of the dialog. Treeherder will send out a request for those jobs to be run, and an action task will be spawned to do all of the behind the scenes magic to make that happen.

=== Pushing Directly ===

It's also possible to push to try directly from hg (for now). This might be required if you're using [https://www.mercurial-scm.org/wiki/MqExtension mercurial queues]. In this case, the only way to select tasks is by manually adding try syntax to your commit message:

$ hg commit -m "try: -b o -p linux64 -u mochitest"
$ hg push -f try

Using |mach try| is recommended as that will automatically create and cleanup a temporary commit no your behalf, whereas with this method you are responsible for cleaning up any extra commits you make or commit messages you modify.

== Viewing the results ==
You can see the results of your tryserver build in a number of ways:

* You'll get an email on a successful push with a link to treeherder for your revision as well as optional emails on any non-successful build/test/talos results
* You can have the results of your try run posted to bug(s) automatically at the completion of the run using the --post-to-bugzilla flag in your try syntax
* The link to treeherder will be printed on the command line.
* Look for your changeset on [https://treeherder.mozilla.org/#/jobs?repo=try Treeherder]. You can add '''&author=YOUR.EMAIL''' to only see your pushes.
* Download your completed builds from [http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/?C=M;O=D firefox/tryserver-builds on ftp.m.o].

== Using a custom mozconfig ==
The mozconfigs for recent mozilla-central clones are located in the browser/config/mozconfigs directory. Edit those as you please.

If you want to apply the same mozconfig changes to multiple platforms, you can edit <tt>build/mozconfig.common.override</tt> instead. This file is included at the end of each of the in-tree mozconfig files.

Android mozconfigs are in mobile/android/config/mozconfigs.

If you modify a mozconfig file named <tt>nightly</tt>, please make sure you also change any mozconfig file named <tt>beta</tt> and/or <tt>release</tt> in the same directory, otherwise the test_compare_mozconfigs test will fail.

Note:
* TryServer purpose is to tell what will happen on Tinderbox, not to check every possible build option/configuration.
** Any non-standard feature is implicitly unsupported. You may try them, but don't complain if they break.

== Getting debug symbols ==
By default native debug symbols are not uploaded for Try server builds because of their size. If you want to debug your builds locally you must add <tt>MOZ_CRASHREPORTER_UPLOAD_FULL_SYMBOLS=1</tt> to the in-tree mozconfigs. You can do this for all platforms by importing [http://hg.mozilla.org/users/tmielczarek_mozilla.com/mq/raw-file/b44faf6cd177/enable-full-symbols this patch] into your mq and pushing it along with your changes to Try. This will cause a ...crashreporter-symbols-full.zip package to be uploaded to the builds directory for each platform built.

== Adding new jobs ==
It's possible to create new jobs (or modify existing ones) directly *in* your try push, provided you use taskcluster. Just edit the relevant configuration in testing/taskcluster. For more information on creating jobs, see the [http://docs.taskcluster.net/ taskcluster docs].

== Desktop l10n jobs ==
You can use the steps in [[ReleaseEngineering/TryServer#Scheduling jobs with Treeherder|Scheduling jobs with Treeherder]] to add localized desktop builds to your try push, regardless of whether you used try syntax at first. Filtering with 'l10n' helps to find the jobs amongst the many possibilities.

The jobs can be customized by modifying files prior to pushing:
* reducing the number of locales by limiting <tt>browser/locales/all-locales</tt> (eg top-locales like de fr ja ja-JP-mac ru zh-TW). Leaving a full list of locales is likely to hit a timeout on Mac and Windows
* use a different en-US build by modifying [https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/single_locale/try.py#4 en_us_binary_url], but note that the building en-US and then l10n in one push is not a tested scenario

The resulting builds are uploaded to the same sub-directory as en-US builds, eg try-linux/ for 32bit linux.

== Desktop l10n jobs (on Taskcluster) ==

To get Desktop l10n jobs on taskcluster on try, simply pass `-b o -p linux64-l10n,linux-l10n` with your try push. You'll also get these jobs automatically with `-p linux64,linux` if you are touching one of the files known to be heavily involved in l10n jobs. (Taskcluster support for other platforms is not yet available)

You can also use the steps in [[ReleaseEngineering/TryServer#Scheduling jobs with Treeherder|Scheduling jobs with Treeherder]] to add localized desktop builds to your try push, regardless of whether you used try syntax at first. Filtering with 'l10n' helps to find the jobs amongst the many possibilities.

The jobs can be customized by modifying files prior to pushing:
* reducing the number of locales by limiting <tt>browser/locales/all-locales</tt> (eg top-locales like de fr ja ja-JP-mac ru zh-TW).
* use a different en-US build by modifying [https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/single_locale/try.py#4 en_us_binary_url], but note that the building en-US and then l10n in one push is not a tested scenario

The resulting builds are uploaded as a task artifact, and are not yet signed.

== Android Single-Locale l10n jobs (on Taskcluster) ==

(NOTE: Only supported on Gecko 51a1 and above)

To get Android l10n jobs on taskcluster on try, simply pass `-p android-api-15-l10n` with your try push. You'll also get these jobs automatically with `-p android-api-15` if you are touching one of the files known to be heavily involved in l10n jobs.

You can also use the steps in [[ReleaseEngineering/TryServer#Scheduling jobs with Treeherder|Scheduling jobs with Treeherder]] to add localized desktop builds to your try push, regardless of whether you used try syntax at first. Filtering with 'l10n' helps to find the jobs amongst the many possibilities.

The jobs can be customized by modifying files prior to pushing:
* reducing the number of locales by limiting <tt>mobile/android/locales/all-locales</tt> (eg top-locales like de fr ru zh-TW).
* use a different en-US build by modifying [https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/single_locale/try_android-api-15.py#3 en_us_binary_url], but note that the building en-US and then l10n in one push is not a tested scenario

The resulting builds are uploaded as a task artifact, and are not yet signed.

== Server Status ==
* Pending builds by revision are at https://secure.pub.build.mozilla.org/buildapi/pending
* In-progress builds by revision are are https://secure.pub.build.mozilla.org/buildapi/running

== Other Notes ==
* Finished builds will live in http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/<your_ldap_email>-<revision> for 14 days before deletion
* Treeherder data is purged after 4 months.
* If you have any problems please [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Release%20Engineering&status_whiteboard=tryserver file a bug]

* Suggestions for the future can be made [[Build:TryServer:Suggestions|here]] or file a blocking bug against {{bug|try_enhancements}}

== Other Mozilla Try Servers ==
* [[ReleaseEngineering/ThunderbirdTryServer|Thunderbird Try Server]] for the comm-central repository

== Problem Diagnosis ==
=== Can not access try server ===
Test your account & configuration
* <code>ssh hg.mozilla.org</code>, response: "No Interactive shells allowed here!"
* <code>ssh hg.mozilla.org clone invalid_sandbox</code>, response: menu display and interactive prompting.

<div id="long_try_push"></div>
=== Pushes to try take a very long time ===
Note: if a fellow developer cancelled their try push, they have saddled you with the cost of rebuilding the cache. (See [http://dtor.com/halfire/2014/07/02/2014_06_try_server_update.html#caching caching] details.)

If you're experiencing excessive wait times (> 45min) pushing to try, please file a bug asking IT to reset the try repository using [https://bugzilla.mozilla.org/enter_bug.cgi?comment=please%20schedule%20a%20reset%20of%20the%20try%20repository%20ASAP%20with%20sheriffs%20%26%20releng.&component=WebOps%3A%20Source%20Control&op_sys=All&product=Infrastructure%20%26%20Operations&rep_platform=All&short_desc=Push%20to%20try%20taking%20XXX%20minutes this template] (please include specifics of your experience). They will coordinate with sheriffs and release engineering as needed.

=== Waiting for Lock ===
If you get a message similar to:
remote: waiting for lock on repository /repo/hg/mozilla/try/ held by 'hgssh1.dmz.scl3.mozilla.com:23974'
remote: abort: repository /repo/hg/mozilla/try/: timed out waiting for lock held by hgssh1.dmz.scl3.mozilla.com:30549
It means several developers are trying to push to try at the same time. In the case above, nothing appears to be wrong, as the PID changes between the messages.

=== Waiting for Lock multiple times with the same pid ===
Similar to the above case, but with the same pid when you retry over and over again.

Please retry your push. If you see messages indicating the same process has been pushing for more than 15 minutes, treat as [[#long_try_push|above]].

== CiDuty issues ==
=== How do I trigger additional talos/test runs for a given try build? ===
If your syntax included the tests you'd like more of, then select the job you want on Treeherder and use the + button. For test suites you didn't request originally you can use the "Add New Jobs" interface in Treeherder.

=== How do I cancel existing jobs? ===
For individual jobs, select the relevant one on Treeherder and use the cancel button. To cancel all jobs, use the menu arrow shown on the header row for each push, and then the "Cancel all" option.

== See Also ==
* https://developer.mozilla.org/en/Creating_Mercurial_User_Repositories
* https://wiki.mozilla.org/Sheriffing/How:To:Recommended_Try_Practices
* https://wiki.mozilla.org/ReleaseEngineering:Autoland
* [http://build.mozilla.org/buildapi/self-serve Manage Submissions] [[https://build.mozilla.org/buildapi/self-serve/try try]]
* [https://catlee.github.io/highscores/highscores.html Scoreboard]

File:Addnewjobssearchselectedjobs.png

2019-09-24T18:48:05Z

KWierso:

Screenshot showing the Add New Jobs (Search) interface with several jobs selected

File:Filteredaddnewjobssearch.png

2019-09-24T18:43:30Z

KWierso:

Screenshot showing a filtered list of jobs in Add New Jobs (Search) mode

File:Addnewjobssearchinterface.png

2019-09-24T18:39:12Z

KWierso:

Screenshot showing the add new jobs (search) interface

File:Add New Jobs Search.png

2019-09-24T18:34:14Z

KWierso:

Screenshot showing the Add New Jobs (Search) menu button

ReleaseEngineering/TryServer

2017-09-26T20:14:26Z

KWierso: Update the addnewjobs section

= Try Server =
The [https://treeherder.mozilla.org/#/jobs?repo=try try server] is an easy way to test a patch without actually checking the patch into the core repository. Your code will go through the same tests as a mozilla-central push, and you'll be able to download builds if you wish.

== Getting access to the Try Server ==
To use the try server, you'll need [http://www.mozilla.org/hacking/commit-access-policy/ Level 1 Commit Access]. You can learn more about Mozilla's commit access policies and start the process of signing up for an account here: [http://www.mozilla.org/hacking/committer/ Becoming a Mozilla Contributor]

After you have level 1 commit access, you'll need to do a bit of setup before you'll be able to push. See [https://developer.mozilla.org/en-US/docs/Mercurial/Using_Mercurial#How_do_I_check_stuff_in.3F this guide] for instructions. Assuming you only have level 1 access, you won't be able to push to mozilla-central, but you can replace 'hg.mozilla.org/mozilla-central' with 'hg.mozilla.org/try'.

== Configuration ==
Before using try, there is some recommended configuration you should set up. This can be accomplished by running:

$ ./mach mercurial-setup

Be sure to at least enable the [http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html firefoxtree extension] and the push-to-try extension. The push-to-try extension is required if you wish to use the |mach try| command (see below). Firefoxtree will give you a handy 'try' alias you can use for pushing, and prevent you from accidentally pushing multiple heads. If for some reason you prefer not to use firefoxtree, you can set the same alias up manually in your hgrc:

[paths]
try = ssh://hg.mozilla.org/try

Note: Never pull the whole try repo. You'll end up with hundreds of heads containing everyone's half baked and broken pushes.

For more information, see [http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/index.html mercurial for mozillians].

== How to push to try ==
There are two ways to schedule jobs on try. You can either push like normal, and select which jobs you want using [https://wiki.mozilla.org/EngineeringProductivity/Projects/Treeherder treeherder], or you can specify a try syntax in your commit message to schedule jobs automatically.

=== Scheduling jobs with Treeherder ===

You can push to try with:

$ ./mach try empty

Once the push succeeds, you can open it in Treeherder and then sign in to schedule jobs manually.

Select the drop-down arrow at the top right of your push, and choose "Add new Jobs". It might take several seconds for the jobs to load ({{bug|1288028}}) :

https://s3.amazonaws.com/media-p.slid.es/uploads/185196/images/2042414/TH_dropdown.png

If it helps, you can use the filter box in the site header to restrict the list of runnable jobs being displayed. Click the job symbols you wish to schedule.

If you select a test job, the required build will automatically be scheduled:

https://s3.amazonaws.com/media-p.slid.es/uploads/185196/images/2042426/TH_with_jobs.png

Finally, click "Trigger New Jobs" near the top right of your push.

NOTE: An action task gets scheduled which will schedule all the tasks you chose.

=== Scheduling jobs with Try Syntax ===
If you know exactly what you want to run, you can use [[Build:TryChooser]] to select which jobs run directly in your commit message. Make sure the commit message containing try syntax is placed in your ''topmost commit''. The [http://trychooser.pub.build.mozilla.org/ TryChooser] web page can help you build a commit message for custom requests. It will generate both a syntax string as well as a mach command you can simply paste into your terminal.

==== Using mach ====
The recommended way to push with a try syntax, is to use |mach try|. It works with both mercurial and git, and you can use the [http://trychooser.pub.build.mozilla.org/ TryChooser] web page to generate the command. For example:

$ mach try -b o -p linux -u mochitest-1 -t none

The |mach try| command also has some advanced features. It can actually change how the job gets run within automation. For example, to run only mochitests under 'dom/indexedDB':

$ mach try -b o -p linux -u mochitests --and dom/indexedDB

For more information see:

$ mach try --help

Note: This method doesn't work well with mq.

==== Using the Trychooser Extension ====
You can also use the [https://bitbucket.org/sfink/trychooser mercurial trychooser extension] from sfink. It has some neat features, like a curses ui that lets you graphically choose a try syntax. Though {{bug|1197868}} tracks implementing this feature in |mach try|. Eventually trychooser will be deprecated in favor of |mach try|.

==== Using mq ====
The aforementioned tools may not play all that nicely with [https://www.mercurial-scm.org/wiki/MqExtension mercurial queues]. If you use mq, you can still push to try manually. First build your try syntax with the [http://trychooser.pub.build.mozilla.org/ TryChooser] web page. Then run:

$ hg qref --message "try: <your-computed-syntax-here>"
$ hg push -f try

== Viewing the results ==
You can see the results of your tryserver build in a number of ways:

* You'll get an email on a successful push with a link to treeherder for your revision as well as optional emails on any non-successful build/test/talos results (this setting can be adjusted using [[Build:TryChooser]] args for email notification)
* You can have the results of your try run posted to bug(s) automatically at the completion of the run using the --post-to-bugzilla flag in your try syntax (see: [[Build:TryChooser]] for examples)
* The link to treeherder will be printed on the command line.
* Look for your changeset on [https://treeherder.mozilla.org/#/jobs?repo=try Treeherder]. You can add '''&author=YOUR.EMAIL''' to only see your pushes.
* Download your completed builds from [http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/?C=M;O=D firefox/tryserver-builds on ftp.m.o].

== Using a custom mozconfig ==
The mozconfigs for recent mozilla-central clones are located in the browser/config/mozconfigs directory. Edit those as you please.

If you want to apply the same mozconfig changes to multiple platforms, you can edit <tt>build/mozconfig.common.override</tt> instead. This file is included at the end of each of the in-tree mozconfig files.

Android mozconfigs are in mobile/android/config/mozconfigs.

Note:
* TryServer purpose is to tell what will happen on Tinderbox, not to check every possible build option/configuration.
** Any non-standard feature is implicitly unsupported. You may try them, but don't complain if they break.

== Getting debug symbols ==
By default native debug symbols are not uploaded for Try server builds because of their size. If you want to debug your builds locally you must add <tt>MOZ_CRASHREPORTER_UPLOAD_FULL_SYMBOLS=1</tt> to the in-tree mozconfigs. You can do this for all platforms by importing [http://hg.mozilla.org/users/tmielczarek_mozilla.com/mq/raw-file/b44faf6cd177/enable-full-symbols this patch] into your mq and pushing it along with your changes to Try. This will cause a ...crashreporter-symbols-full.zip package to be uploaded to the builds directory for each platform built.

== Adding new jobs ==
It's possible to create new jobs (or modify existing ones) directly *in* your try push, provided you use taskcluster. Just edit the relevant configuration in testing/taskcluster. For more information on creating jobs, see the [http://docs.taskcluster.net/ taskcluster docs].

== Desktop l10n jobs ==
You can use the steps in [[ReleaseEngineering/TryServer#Scheduling jobs with Treeherder|Scheduling jobs with Treeherder]] to add localized desktop builds to your try push, regardless of whether you used try syntax at first. Filtering with 'l10n' helps to find the jobs amongst the many possibilities.

The jobs can be customized by modifying files prior to pushing:
* reducing the number of locales by limiting <tt>browser/locales/all-locales</tt> (eg top-locales like de fr ja ja-JP-mac ru zh-TW). Leaving a full list of locales is likely to hit a timeout on Mac and Windows
* use a different en-US build by modifying [https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/single_locale/try.py#4 en_us_binary_url], but note that the building en-US and then l10n in one push is not a tested scenario

The resulting builds are uploaded to the same sub-directory as en-US builds, eg try-linux/ for 32bit linux.

== Desktop l10n jobs (on Taskcluster) ==

To get Desktop l10n jobs on taskcluster on try, simply pass `-b o -p linux64-l10n,linux-l10n` with your try push. You'll also get these jobs automatically with `-p linux64,linux` if you are touching one of the files known to be heavily involved in l10n jobs. (Taskcluster support for other platforms is not yet available)

You can also use the steps in [[ReleaseEngineering/TryServer#Scheduling jobs with Treeherder|Scheduling jobs with Treeherder]] to add localized desktop builds to your try push, regardless of whether you used try syntax at first. Filtering with 'l10n' helps to find the jobs amongst the many possibilities.

The jobs can be customized by modifying files prior to pushing:
* reducing the number of locales by limiting <tt>browser/locales/all-locales</tt> (eg top-locales like de fr ja ja-JP-mac ru zh-TW).
* use a different en-US build by modifying [https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/single_locale/try.py#4 en_us_binary_url], but note that the building en-US and then l10n in one push is not a tested scenario

The resulting builds are uploaded as a task artifact, and are not yet signed.

== Android Single-Locale l10n jobs (on Taskcluster) ==

(NOTE: Only supported on Gecko 51a1 and above)

To get Android l10n jobs on taskcluster on try, simply pass `-p android-api-15-l10n` with your try push. You'll also get these jobs automatically with `-p android-api-15` if you are touching one of the files known to be heavily involved in l10n jobs.

You can also use the steps in [[ReleaseEngineering/TryServer#Scheduling jobs with Treeherder|Scheduling jobs with Treeherder]] to add localized desktop builds to your try push, regardless of whether you used try syntax at first. Filtering with 'l10n' helps to find the jobs amongst the many possibilities.

The jobs can be customized by modifying files prior to pushing:
* reducing the number of locales by limiting <tt>mobile/android/locales/all-locales</tt> (eg top-locales like de fr ru zh-TW).
* use a different en-US build by modifying [https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/configs/single_locale/try_android-api-15.py#3 en_us_binary_url], but note that the building en-US and then l10n in one push is not a tested scenario

The resulting builds are uploaded as a task artifact, and are not yet signed.

== Server Status ==
* Pending builds by revision are at https://secure.pub.build.mozilla.org/buildapi/pending
* In-progress builds by revision are are https://secure.pub.build.mozilla.org/buildapi/running

== Other Notes ==
* Finished builds will live in http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/<your_ldap_email>-<revision> for 14 days before deletion
* Treeherder data is purged after 4 months.
* If you have any problems please [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Release%20Engineering&status_whiteboard=tryserver file a bug]

* Suggestions for the future can be made [[Build:TryServer:Suggestions|here]] or file a blocking bug against {{bug|try_enhancements}}

== Other Mozilla Try Servers ==
* [[ReleaseEngineering/ThunderbirdTryServer|Thunderbird Try Server]] for the comm-central repository

== Problem Diagnosis ==
=== Can not access try server ===
Test your account & configuration
* <code>ssh hg.mozilla.org</code>, response: "No Interactive shells allowed here!"
* <code>ssh hg.mozilla.org clone invalid_sandbox</code>, response: menu display and interactive prompting.

<div id="long_try_push"></div>
=== Pushes to try take a very long time ===
Note: if a fellow developer cancelled their try push, they have saddled you with the cost of rebuilding the cache. (See [http://dtor.com/halfire/2014/07/02/2014_06_try_server_update.html#caching caching] details.)

If you're experiencing excessive wait times (> 45min) pushing to try, please file a bug asking IT to reset the try repository using [https://bugzilla.mozilla.org/enter_bug.cgi?comment=please%20schedule%20a%20reset%20of%20the%20try%20repository%20ASAP%20with%20sheriffs%20%26%20releng.&component=WebOps%3A%20Source%20Control&op_sys=All&product=Infrastructure%20%26%20Operations&rep_platform=All&short_desc=Push%20to%20try%20taking%20XXX%20minutes this template] (please include specifics of your experience). They will coordinate with sheriffs and release engineering as needed.

=== Waiting for Lock ===
If you get a message similar to:
remote: waiting for lock on repository /repo/hg/mozilla/try/ held by 'hgssh1.dmz.scl3.mozilla.com:23974'
remote: abort: repository /repo/hg/mozilla/try/: timed out waiting for lock held by hgssh1.dmz.scl3.mozilla.com:30549
It means several developers are trying to push to try at the same time. In the case above, nothing appears to be wrong, as the PID changes between the messages.

=== Waiting for Lock multiple times with the same pid ===
Similar to the above case, but with the same pid when you retry over and over again.

Please retry your push. If you see messages indicating the same process has been pushing for more than 15 minutes, treat as [[#long_try_push|above]].

== Buildduty issues ==
=== How do I trigger additional talos/test runs for a given try build? ===
If your trychooser syntax included the tests you'd like more of, then select the job you want on Treeherder and use the + button. For test suites you didn't request originally you can use the "Add New Jobs" interface in Treeherder.

=== How do I cancel existing jobs? ===
For individual jobs, select the relevant one on Treeherder and use the cancel button. To cancel all jobs, use the menu arrow shown on the header row for each push, and then the "Cancel all" option.

=== TryChooser ===
See the [[ReleaseEngineering/TryChooser#Buildduty_Issues|TryChooser]] wiki page.

== See Also ==
* https://developer.mozilla.org/en/Creating_Mercurial_User_Repositories
* http://trychooser.pub.build.mozilla.org/
* https://wiki.mozilla.org/Sheriffing/How:To:Recommended_Try_Practices
* https://wiki.mozilla.org/Build:TryChooser
* https://wiki.mozilla.org/ReleaseEngineering:Autoland
* [http://build.mozilla.org/buildapi/self-serve Manage Submissions] [[https://build.mozilla.org/buildapi/self-serve/try try]]
* [https://secure.pub.build.mozilla.org/builddata/reports/reportor/daily/highscores/highscores.html Scoreboard]

Sheriffing/How To/Retrigger Jobs

2017-08-08T19:46:13Z

KWierso: Describe how to schedule PGO builds in the brave new Taskcluster world

{{Sheriffing How To|Retrigger jobs}}
__TOC__
Sometimes builds and tests need to be retriggered. For some classes of automation/infrastructure failures, this happens automatically and the job is marked in the [https://treeherder.mozilla.org/userguide.html Treeherder UI] as dark blue. For other cases, or if you're doing investigative work e.g. testing for an intermittent failure, you'll need to retrigger the job manually.

= Manual retriggers =
* Select a job result in Treeherder and click on it.
* This will display a results pane in the left bottom corner with information like Job, Machine, Task, etc.
* To retrigger this job/test, click on the circular arrow with the mouseover text of "Repeat the selected job" at the top of the results pane and the job will be retriggered. You can accomplish the same thing by simply pressing "r" in the results pane when you are logged in to Treeherder.

= Retriggering PGO Builds =

With the recent switch to Taskcluster-based builds, every push to inbound/autoland now automatically schedules PGO builds for Linux and Windows, so they can be retriggered manually as needed within Treeherder, just like any other failed job.

Release/ESR52 still need to use self-serve to manually schedule PGO builds. Click the "BuildAPI" link on the desired push in Treeherder, copy the push's revision, paste it into the "Create new PGO builds on <tree>" textbox, and click "Submit" to request them.

= Retriggering Nightly Builds =

As of Jul 26, 2017 nightly builds for all platforms on m-c are now running in taskcluster so the instructions on how to respin them have been updated for these platforms
See https://wiki.mozilla.org/ReleaseEngineering/Buildduty/Other_Duties#Nightlies

'''CAVEAT''': there are implications to triggering too many Nightly builds in a single day or in quick succession. Please talk with a sheriff first before retriggering Nightly builds.

Release/ESR52 still need to use self-serve to manually schedule Nightly builds. Click the "BuildAPI" link on the desired push in Treeherder, copy the push's revision, paste it into the "Create new nightly builds on <tree>" textbox, and click "Submit" to request them.

Sheriffing/How To/Retrigger Jobs

2017-08-08T19:37:23Z

KWierso: Remove the buildbot rules for triggering Nightlies

{{Sheriffing How To|Retrigger jobs}}
__TOC__
Sometimes builds and tests need to be retriggered. For some classes of automation/infrastructure failures, this happens automatically and the job is marked in the [https://treeherder.mozilla.org/userguide.html Treeherder UI] as dark blue. For other cases, or if you're doing investigative work e.g. testing for an intermittent failure, you'll need to retrigger the job manually.

= Manual retriggers =
* Select a job result in Treeherder and click on it.
* This will display a results pane in the left bottom corner with information like Job, Machine, Task, etc.
* To retrigger this job/test, click on the circular arrow with the mouseover text of "Repeat the selected job" at the top of the results pane and the job will be retriggered. You can accomplish the same thing by simply pressing "r" in the results pane when you are logged in to Treeherder.

= Retriggering PGO Builds =
PGO ('''P'''rofile-'''G'''uided '''O''''ptimization) builds can break, just like anything else. When you fix the bustage with a backout or with help from a developer, you can trigger PGO builds to verify that the issue is fixed.

To retrigger PGO builds on your changeset:
* Go the buildapi self-serve page for mozilla-central: https://secure.pub.build.mozilla.org/buildapi/self-serve/mozilla-central
* Input your changeset into the box labelled "Create new PGO builds on mozilla-central revision" at the bottom of the page.
* Click Submit

= Retriggering Nightly Builds =

As of Jul 26, 2017 nightly builds for all platforms on m-c are now running in taskcluster so the instructions on how to respin them have been updated for these platforms
See https://wiki.mozilla.org/ReleaseEngineering/Buildduty/Other_Duties#Nightlies

'''CAVEAT''': there are implications to triggering too many Nightly builds in a single day or in quick succession. Please talk with a sheriff first before retriggering Nightly builds.

Sheriffing/How To/Unified Repos

2017-08-08T01:10:32Z

KWierso: Drop references to fx-team

{{Sheriffing How To|Unified repos}}
= Unified Repos =
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

== Setting up the repo ==
* Set up your ssh key yourself
* Install [https://www.mercurial-scm.org/downloads Mercurial 4.2] or higher
* Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* cd mozilla-central
* ./mach mercurial-setup

Configure mercurial as desired. At a minimum, you need the following:
* Set your username and email.
* Enable the firefoxtree extension.
* Enable the histedit extension.

The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull autoland && hg pull beta && hg pull release && hg pull esr52
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

If you want, you can rename the mozilla-central folder to something like "unified", since it is more than just mozilla-central at this point.

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

To pull in newly landed changes, you can use one of the following commands:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound and autoland branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

== Merges ==
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, autoland, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

== Checkin-neededs ==
This assumes we're checking things in to autoland. Replace autoland with another branch name as needed.

==== Single repository and single set of patches ====
Update autoland and prepare for the patches:
* hg pull autoland
* hg up autoland
* hg bookmark autoland-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all autoland checkin-needed patches
Verify your outgoing changes:
* hg out -r . autoland
If you haven't lost a push race:
* hg push -r . autoland
If you lost a push race:
* hg pull autoland
* hg rebase -d autoland
* hg push -r . autoland
Delete your no longer needed bookmark:
* hg bookmark -d autoland-checkins

==== Multiple repositories with a single set of patches each ====
You can set up multiple sets of patches at once against multiple repositories:
Update autoland
* hg pull autoland && hg up autoland
Create a bookmark to base your autoland checkin-needed patches
* hg bookmark autoland-checkins
Import a bunch of patches against autoland
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your autoland checkins and add another patch to the bookmark, then push it
* hg up autoland-checkins
* hg import <patch5>
* hg out -r . autoland # this will be patch1, patch2, and patch5
* hg push -r . autoland
* hg bookmark -d autoland-checkins

==== Single repository with multiple sets of patches ====
Or have multiple sets of patches against a single repository:
Update autoland
* hg pull autoland && hg up autoland
Make the first bookmark/set
* hg bookmark autoland-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up autoland && hg bookmark autoland-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . autoland # patch3 and patch4
* hg up autoland-checkins-1 && hg out -r . autoland # patch1 and patch2
Push the first set
* hg push -r . autoland # pushes patch1 and patch2
Get ready to push the second set
* hg up autoland-checkins-2
* hg rebase -d autoland # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . autoland # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d autoland-checkins-1
* hg bookmark -d autoland-checkins-2

== Uplifts ==
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

== Backouts ==
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* hg backout -r <revision>
** 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).
* hg push -r . <tree>

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can still be used, though you will want to use `hg oops` in place of `hg qbackout` (eg if you use `hg share` to get multiple working directories, qbackout and other uses of mq do not play nice with shared repos):
* Copy the backout <revision> from treeherder
* hg oops -e -r <revision>
** This should open up your editor with a prepopulated commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg out -r . <tree>
** to double-check what you will be pushing
* hg push -r . <tree>

qbackout can also back out a range of commits in a single backout commit:
* hg oops -e -s -r <toprevision>:<bottomrevision>
** This will open your editor with a prepopulated commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg push -r . <tree>
(Omit oops's -s flag to back out each individual revision in the range as a separate commit.)

=== Revert a backout ===
* `hg graft`, see https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

== Rebasing after losing a push race ==
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

== Recovering from mistakes ==
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on autoland, both inbound and autoland will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

You may also need to use some combination of the following to get things back to a known-good state:
* hg purge # http://mercurial.selenic.com/wiki/PurgeExtension
* hg up -C

== See what you're about to push ==
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

== View incoming changes ==
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from autoland's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of autoland's changesets:
* hg pull autoland
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on autoland (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

== See the log for a particular branch ==
* hg log -fr [branch]

= Extras =
== hg aliases ==
=== mergetocentral/mergetointegration ===
I set up the following aliases in my global .hgrc file to make merging things around trunk a little faster:
[alias]
# merge tree $1, revision $2 to central, optionally appending $3 (for "CLOSED TREE", etc)
mergetocentral = !$HG pull central ; $HG up central ; $HG pull $1 ; $HG merge $2 ; $HG commit -m "Merge $1 to central, a=merge $3" ; $HG push -r . central
# merge central tip to tree $1, optionally appending $2 (for "CLOSED TREE", etc)
mergetointegration = !$HG pull central ; $HG pull $1 ; $HG up $1 ; $HG merge central ; $HG commit -m "Merge m-c to $1, a=merge $2" ; $HG push -r . $1

With these set up, I can merge autoland's revision 04a3d9130aa0 over to mozilla-central with the following command:
hg mergetocentral autoland 04a3d9130aa0
and then I can merge mozilla-central's tip back to autoland with the following command:
hg mergetointegration autoland
This cuts down on a lot of repetitive typing, saving a bit of time.

=== rbimport ===
For merging from reviewboard patches, there's this alias
rbimport = !hg transplant -e -s https://reviewboard-hg.mozilla.org/gecko -b $1

Then, it's matter of importing the right hash like the following command:
hg rbimport dd1462ba321db983061b94e30cee92b6bd81e908

Sheriffing/How To/Unified Repos

2017-08-08T01:10:14Z

KWierso: Drop references to fx-team

{{Sheriffing How To|Unified repos}}
= Unified Repos =
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

== Setting up the repo ==
* Set up your ssh key yourself
* Install [https://www.mercurial-scm.org/downloads Mercurial 4.2] or higher
* Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* cd mozilla-central
* ./mach mercurial-setup

Configure mercurial as desired. At a minimum, you need the following:
* Set your username and email.
* Enable the firefoxtree extension.
* Enable the histedit extension.

The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull autoland && hg pull beta && hg pull release && hg pull esr52
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

If you want, you can rename the mozilla-central folder to something like "unified", since it is more than just mozilla-central at this point.

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

To pull in newly landed changes, you can use one of the following commands:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound and autoland branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

== Merges ==
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, autoland, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

== Checkin-neededs ==
This assumes we're checking things in to autoland. Replace autoland with another branch name as needed.

==== Single repository and single set of patches ====
Update autoland and prepare for the patches:
* hg pull autoland
* hg up autoland
* hg bookmark autoland-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all autoland checkin-needed patches
Verify your outgoing changes:
* hg out -r . autoland
If you haven't lost a push race:
* hg push -r . autoland
If you lost a push race:
* hg pull autoland
* hg rebase -d autoland
* hg push -r . autoland
Delete your no longer needed bookmark:
* hg bookmark -d autoland-checkins

==== Multiple repositories with a single set of patches each ====
You can set up multiple sets of patches at once against multiple repositories:
Update autoland
* hg pull autoland && hg up autoland
Create a bookmark to base your autoland checkin-needed patches
* hg bookmark autoland-checkins
Import a bunch of patches against autoland
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your autoland checkins and add another patch to the bookmark, then push it
* hg up autoland-checkins
* hg import <patch5>
* hg out -r . autoland # this will be patch1, patch2, and patch5
* hg push -r . autoland
* hg bookmark -d autoland-checkins

==== Single repository with multiple sets of patches ====
Or have multiple sets of patches against a single repository:
Update autoland
* hg pull autoland && hg up autoland
Make the first bookmark/set
* hg bookmark autoland-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up autoland && hg bookmark autoland-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . autoland # patch3 and patch4
* hg up autoland-checkins-1 && hg out -r . autoland # patch1 and patch2
Push the first set
* hg push -r . autoland # pushes patch1 and patch2
Get ready to push the second set
* hg up autoland-checkins-2
* hg rebase -d autoland # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . autoland # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d autoland-checkins-1
* hg bookmark -d autoland-checkins-2

== Uplifts ==
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

== Backouts ==
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* hg backout -r <revision>
** 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).
* hg push -r . <tree>

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can still be used, though you will want to use `hg oops` in place of `hg qbackout` (eg if you use `hg share` to get multiple working directories, qbackout and other uses of mq do not play nice with shared repos):
* Copy the backout <revision> from treeherder
* hg oops -e -r <revision>
** This should open up your editor with a prepopulated commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg out -r . <tree>
** to double-check what you will be pushing
* hg push -r . <tree>

qbackout can also back out a range of commits in a single backout commit:
* hg oops -e -s -r <toprevision>:<bottomrevision>
** This will open your editor with a prepopulated commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg push -r . <tree>
(Omit oops's -s flag to back out each individual revision in the range as a separate commit.)

=== Revert a backout ===
* `hg graft`, see https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

== Rebasing after losing a push race ==
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

== Recovering from mistakes ==
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on autoland, both inbound and autoland will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

You may also need to use some combination of the following to get things back to a known-good state:
* hg purge # http://mercurial.selenic.com/wiki/PurgeExtension
* hg up -C

== See what you're about to push ==
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

== View incoming changes ==
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of autoland's changesets:
* hg pull autoland
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on autoland (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

== See the log for a particular branch ==
* hg log -fr [branch]

= Extras =
== hg aliases ==
=== mergetocentral/mergetointegration ===
I set up the following aliases in my global .hgrc file to make merging things around trunk a little faster:
[alias]
# merge tree $1, revision $2 to central, optionally appending $3 (for "CLOSED TREE", etc)
mergetocentral = !$HG pull central ; $HG up central ; $HG pull $1 ; $HG merge $2 ; $HG commit -m "Merge $1 to central, a=merge $3" ; $HG push -r . central
# merge central tip to tree $1, optionally appending $2 (for "CLOSED TREE", etc)
mergetointegration = !$HG pull central ; $HG pull $1 ; $HG up $1 ; $HG merge central ; $HG commit -m "Merge m-c to $1, a=merge $2" ; $HG push -r . $1

With these set up, I can merge autoland's revision 04a3d9130aa0 over to mozilla-central with the following command:
hg mergetocentral autoland 04a3d9130aa0
and then I can merge mozilla-central's tip back to autoland with the following command:
hg mergetointegration autoland
This cuts down on a lot of repetitive typing, saving a bit of time.

=== rbimport ===
For merging from reviewboard patches, there's this alias
rbimport = !hg transplant -e -s https://reviewboard-hg.mozilla.org/gecko -b $1

Then, it's matter of importing the right hash like the following command:
hg rbimport dd1462ba321db983061b94e30cee92b6bd81e908

Sheriffing/How To/Unified Repos

2017-08-08T01:09:34Z

KWierso:

{{Sheriffing How To|Unified repos}}
= Unified Repos =
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

== Setting up the repo ==
* Set up your ssh key yourself
* Install [https://www.mercurial-scm.org/downloads Mercurial 4.2] or higher
* Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* cd mozilla-central
* ./mach mercurial-setup

Configure mercurial as desired. At a minimum, you need the following:
* Set your username and email.
* Enable the firefoxtree extension.
* Enable the histedit extension.

The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull autoland && hg pull beta && hg pull release && hg pull esr52
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

If you want, you can rename the mozilla-central folder to something like "unified", since it is more than just mozilla-central at this point.

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

To pull in newly landed changes, you can use one of the following commands:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound and autoland branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

== Merges ==
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, autoland, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

== Checkin-neededs ==
This assumes we're checking things in to autoland. Replace autoland with another branch name as needed.

==== Single repository and single set of patches ====
Update autoland and prepare for the patches:
* hg pull autoland
* hg up autoland
* hg bookmark autoland-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all autoland checkin-needed patches
Verify your outgoing changes:
* hg out -r . autoland
If you haven't lost a push race:
* hg push -r . autoland
If you lost a push race:
* hg pull autoland
* hg rebase -d autoland
* hg push -r . autoland
Delete your no longer needed bookmark:
* hg bookmark -d autoland-checkins

==== Multiple repositories with a single set of patches each ====
You can set up multiple sets of patches at once against multiple repositories:
Update autoland
* hg pull autoland && hg up autoland
Create a bookmark to base your autoland checkin-needed patches
* hg bookmark autoland-checkins
Import a bunch of patches against autoland
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your autoland checkins and add another patch to the bookmark, then push it
* hg up autoland-checkins
* hg import <patch5>
* hg out -r . autoland # this will be patch1, patch2, and patch5
* hg push -r . autoland
* hg bookmark -d autoland-checkins

==== Single repository with multiple sets of patches ====
Or have multiple sets of patches against a single repository:
Update autoland
* hg pull autoland && hg up autoland
Make the first bookmark/set
* hg bookmark autoland-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up autoland && hg bookmark autoland-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . autoland # patch3 and patch4
* hg up autoland-checkins-1 && hg out -r . autoland # patch1 and patch2
Push the first set
* hg push -r . autoland # pushes patch1 and patch2
Get ready to push the second set
* hg up autoland-checkins-2
* hg rebase -d autoland # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . autoland # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d autoland-checkins-1
* hg bookmark -d autoland-checkins-2

== Uplifts ==
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

== Backouts ==
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* hg backout -r <revision>
** 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).
* hg push -r . <tree>

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can still be used, though you will want to use `hg oops` in place of `hg qbackout` (eg if you use `hg share` to get multiple working directories, qbackout and other uses of mq do not play nice with shared repos):
* Copy the backout <revision> from treeherder
* hg oops -e -r <revision>
** This should open up your editor with a prepopulated commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg out -r . <tree>
** to double-check what you will be pushing
* hg push -r . <tree>

qbackout can also back out a range of commits in a single backout commit:
* hg oops -e -s -r <toprevision>:<bottomrevision>
** This will open your editor with a prepopulated commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg push -r . <tree>
(Omit oops's -s flag to back out each individual revision in the range as a separate commit.)

=== Revert a backout ===
* `hg graft`, see https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

== Rebasing after losing a push race ==
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

== Recovering from mistakes ==
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on autoland, both inbound and autoland will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

You may also need to use some combination of the following to get things back to a known-good state:
* hg purge # http://mercurial.selenic.com/wiki/PurgeExtension
* hg up -C

== See what you're about to push ==
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

== View incoming changes ==
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

== See the log for a particular branch ==
* hg log -fr [branch]

= Extras =
== hg aliases ==
=== mergetocentral/mergetointegration ===
I set up the following aliases in my global .hgrc file to make merging things around trunk a little faster:
[alias]
# merge tree $1, revision $2 to central, optionally appending $3 (for "CLOSED TREE", etc)
mergetocentral = !$HG pull central ; $HG up central ; $HG pull $1 ; $HG merge $2 ; $HG commit -m "Merge $1 to central, a=merge $3" ; $HG push -r . central
# merge central tip to tree $1, optionally appending $2 (for "CLOSED TREE", etc)
mergetointegration = !$HG pull central ; $HG pull $1 ; $HG up $1 ; $HG merge central ; $HG commit -m "Merge m-c to $1, a=merge $2" ; $HG push -r . $1

With these set up, I can merge autoland's revision 04a3d9130aa0 over to mozilla-central with the following command:
hg mergetocentral autoland 04a3d9130aa0
and then I can merge mozilla-central's tip back to autoland with the following command:
hg mergetointegration autoland
This cuts down on a lot of repetitive typing, saving a bit of time.

=== rbimport ===
For merging from reviewboard patches, there's this alias
rbimport = !hg transplant -e -s https://reviewboard-hg.mozilla.org/gecko -b $1

Then, it's matter of importing the right hash like the following command:
hg rbimport dd1462ba321db983061b94e30cee92b6bd81e908

Sheriffing/How To/Unified Repos

2017-08-08T01:08:59Z

KWierso: Drop references to fx-team

{{Sheriffing How To|Unified repos}}
= Unified Repos =
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

== Setting up the repo ==
* Set up your ssh key yourself
* Install [https://www.mercurial-scm.org/downloads Mercurial 4.2] or higher
* Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* cd mozilla-central
* ./mach mercurial-setup

Configure mercurial as desired. At a minimum, you need the following:
* Set your username and email.
* Enable the firefoxtree extension.
* Enable the histedit extension.

The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull autoland && hg pull beta && hg pull release && hg pull esr52
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

If you want, you can rename the mozilla-central folder to something like "unified", since it is more than just mozilla-central at this point.

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

To pull in newly landed changes, you can use one of the following commands:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound and autoland branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

== Merges ==
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, autoland, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

== Checkin-neededs ==
This assumes we're checking things in to autoland. Replace autoland with another branch name as needed.

==== Single repository and single set of patches ====
Update autoland and prepare for the patches:
* hg pull autoland
* hg up autoland
* hg bookmark autoland-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all autoland checkin-needed patches
Verify your outgoing changes:
* hg out -r . autoland
If you haven't lost a push race:
* hg push -r . autoland
If you lost a push race:
* hg pull autoland
* hg rebase -d autoland
* hg push -r . autoland
Delete your no longer needed bookmark:
* hg bookmark -d autoland-checkins

==== Multiple repositories with a single set of patches each ====
You can set up multiple sets of patches at once against multiple repositories:
Update autoland
* hg pull autoland && hg up autoland
Create a bookmark to base your autoland checkin-needed patches
* hg bookmark autoland-checkins
Import a bunch of patches against autoland
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your autoland checkins and add another patch to the bookmark, then push it
* hg up autoland-checkins
* hg import <patch5>
* hg out -r . autoland # this will be patch1, patch2, and patch5
* hg push -r . autoland
* hg bookmark -d autoland-checkins

==== Single repository with multiple sets of patches ====
Or have multiple sets of patches against a single repository:
Update autoland
* hg pull autoland && hg up autoland
Make the first bookmark/set
* hg bookmark autoland-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up autoland && hg bookmark autoland-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . autoland # patch3 and patch4
* hg up autoland-checkins-1 && hg out -r . autoland # patch1 and patch2
Push the first set
* hg push -r . autoland # pushes patch1 and patch2
Get ready to push the second set
* hg up autoland-checkins-2
* hg rebase -d autoland # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . autoland # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d autoland-checkins-1
* hg bookmark -d autoland-checkins-2

== Uplifts ==
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

== Backouts ==
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* hg backout -r <revision>
** 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).
* hg push -r . <tree>

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can still be used, though you will want to use `hg oops` in place of `hg qbackout` (eg if you use `hg share` to get multiple working directories, qbackout and other uses of mq do not play nice with shared repos):
* Copy the backout <revision> from treeherder
* hg oops -e -r <revision>
** This should open up your editor with a prepopulated commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg out -r . <tree>
** to double-check what you will be pushing
* hg push -r . <tree>

qbackout can also back out a range of commits in a single backout commit:
* hg oops -e -s -r <toprevision>:<bottomrevision>
** This will open your editor with a prepopulated commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg push -r . <tree>
(Omit oops's -s flag to back out each individual revision in the range as a separate commit.)

=== Revert a backout ===
* `hg graft`, see https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

== Rebasing after losing a push race ==
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

== Recovering from mistakes ==
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on autoland, both inbound and autoland will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

You may also need to use some combination of the following to get things back to a known-good state:
* hg purge # http://mercurial.selenic.com/wiki/PurgeExtension
* hg up -C

== See what you're about to push ==
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

== View incoming changes ==
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

== See the log for a particular branch ==
* hg log -fr [branch]

= Extras =
== hg aliases ==
=== mergetocentral/mergetointegration ===
I set up the following aliases in my global .hgrc file to make merging things around trunk a little faster:
[alias]
# merge tree $1, revision $2 to central, optionally appending $3 (for "CLOSED TREE", etc)
mergetocentral = !$HG pull central ; $HG up central ; $HG pull $1 ; $HG merge $2 ; $HG commit -m "Merge $1 to central, a=merge $3" ; $HG push -r . central
# merge central tip to tree $1, optionally appending $2 (for "CLOSED TREE", etc)
mergetointegration = !$HG pull central ; $HG pull $1 ; $HG up $1 ; $HG merge central ; $HG commit -m "Merge m-c to $1, a=merge $2" ; $HG push -r . $1

With these set up, I can merge fx-team's revision 04a3d9130aa0 over to mozilla-central with the following command:
hg mergetocentral fx-team 04a3d9130aa0
and then I can merge mozilla-central's tip back to fx-team with the following command:
hg mergetointegration fx-team
This cuts down on a lot of repetitive typing, saving a bit of time.

=== rbimport ===
For merging from reviewboard patches, there's this alias
rbimport = !hg transplant -e -s https://reviewboard-hg.mozilla.org/gecko -b $1

Then, it's matter of importing the right hash like the following command:
hg rbimport dd1462ba321db983061b94e30cee92b6bd81e908

Sheriffing/How To/Unified Repos

2017-08-08T01:08:01Z

KWierso: Drop references to fx-team

{{Sheriffing How To|Unified repos}}
= Unified Repos =
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

== Setting up the repo ==
* Set up your ssh key yourself
* Install [https://www.mercurial-scm.org/downloads Mercurial 4.2] or higher
* Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* cd mozilla-central
* ./mach mercurial-setup

Configure mercurial as desired. At a minimum, you need the following:
* Set your username and email.
* Enable the firefoxtree extension.
* Enable the histedit extension.

The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull autoland && hg pull beta && hg pull release && hg pull esr52
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

If you want, you can rename the mozilla-central folder to something like "unified", since it is more than just mozilla-central at this point.

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

To pull in newly landed changes, you can use one of the following commands:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound and autoland branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

== Merges ==
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, autoland, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

== Checkin-neededs ==
This assumes we're checking things in to autoland. Replace autoland with another branch name as needed.

==== Single repository and single set of patches ====
Update autoland and prepare for the patches:
* hg pull autoland
* hg up autoland
* hg bookmark autoland-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all autoland checkin-needed patches
Verify your outgoing changes:
* hg out -r . autoland
If you haven't lost a push race:
* hg push -r . autoland
If you lost a push race:
* hg pull autoland
* hg rebase -d autoland
* hg push -r . autoland
Delete your no longer needed bookmark:
* hg bookmark -d autoland-checkins

==== Multiple repositories with a single set of patches each ====
You can set up multiple sets of patches at once against multiple repositories:
Update autoland
* hg pull autoland && hg up autoland
Create a bookmark to base your autoland checkin-needed patches
* hg bookmark autoland-checkins
Import a bunch of patches against autoland
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your autoland checkins and add another patch to the bookmark, then push it
* hg up autoland-checkins
* hg import <patch5>
* hg out -r . autoland # this will be patch1, patch2, and patch5
* hg push -r . autoland
* hg bookmark -d autoland-checkins

==== Single repository with multiple sets of patches ====
Or have multiple sets of patches against a single repository:
Update autoland
* hg pull autoland && hg up autoland
Make the first bookmark/set
* hg bookmark autoland-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up autoland && hg bookmark autoland-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . autoland # patch3 and patch4
* hg up autoland-checkins-1 && hg out -r . autoland # patch1 and patch2
Push the first set
* hg push -r . autoland # pushes patch1 and patch2
Get ready to push the second set
* hg up autoland-checkins-2
* hg rebase -d autoland # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . autoland # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d autoland-checkins-1
* hg bookmark -d autoland-checkins-2

== Uplifts ==
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

== Backouts ==
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* hg backout -r <revision>
** 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).
* hg push -r . <tree>

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can still be used, though you will want to use `hg oops` in place of `hg qbackout` (eg if you use `hg share` to get multiple working directories, qbackout and other uses of mq do not play nice with shared repos):
* Copy the backout <revision> from treeherder
* hg oops -e -r <revision>
** This should open up your editor with a prepopulated commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg out -r . <tree>
** to double-check what you will be pushing
* hg push -r . <tree>

qbackout can also back out a range of commits in a single backout commit:
* hg oops -e -s -r <toprevision>:<bottomrevision>
** This will open your editor with a prepopulated commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg push -r . <tree>
(Omit oops's -s flag to back out each individual revision in the range as a separate commit.)

=== Revert a backout ===
* `hg graft`, see https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

== Rebasing after losing a push race ==
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

== Recovering from mistakes ==
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

You may also need to use some combination of the following to get things back to a known-good state:
* hg purge # http://mercurial.selenic.com/wiki/PurgeExtension
* hg up -C

== See what you're about to push ==
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

== View incoming changes ==
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

== See the log for a particular branch ==
* hg log -fr [branch]

= Extras =
== hg aliases ==
=== mergetocentral/mergetointegration ===
I set up the following aliases in my global .hgrc file to make merging things around trunk a little faster:
[alias]
# merge tree $1, revision $2 to central, optionally appending $3 (for "CLOSED TREE", etc)
mergetocentral = !$HG pull central ; $HG up central ; $HG pull $1 ; $HG merge $2 ; $HG commit -m "Merge $1 to central, a=merge $3" ; $HG push -r . central
# merge central tip to tree $1, optionally appending $2 (for "CLOSED TREE", etc)
mergetointegration = !$HG pull central ; $HG pull $1 ; $HG up $1 ; $HG merge central ; $HG commit -m "Merge m-c to $1, a=merge $2" ; $HG push -r . $1

With these set up, I can merge fx-team's revision 04a3d9130aa0 over to mozilla-central with the following command:
hg mergetocentral fx-team 04a3d9130aa0
and then I can merge mozilla-central's tip back to fx-team with the following command:
hg mergetointegration fx-team
This cuts down on a lot of repetitive typing, saving a bit of time.

=== rbimport ===
For merging from reviewboard patches, there's this alias
rbimport = !hg transplant -e -s https://reviewboard-hg.mozilla.org/gecko -b $1

Then, it's matter of importing the right hash like the following command:
hg rbimport dd1462ba321db983061b94e30cee92b6bd81e908

Sheriffing/How To/Unified Repos

2017-07-26T07:19:17Z

KWierso: Partial cleanup/update

== Unified Repos ==
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

=== Setting up the repo ===
* Set up your ssh key yourself
* Install [https://www.mercurial-scm.org/downloads Mercurial 4.2] or higher
* Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* cd mozilla-central
* ./mach mercurial-setup

Configure mercurial as desired. At a minimum, you need the following:
* Set your username and email.
* Enable the firefoxtree extension.
* Enable the histedit extension.

The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull autoland && hg pull beta && hg pull release && hg pull esr52
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

If you want, you can rename the mozilla-central folder to something like "unified", since it is more than just mozilla-central at this point.

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

To pull in newly landed changes, you can use one of the following commands:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound and autoland branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

=== Merges ===
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, autoland, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

=== Checkin-neededs ===
This assumes we're checking things in to fx-team. Replace fx-team with another branch name as needed.

===== Single repository and single set of patches =====
Update fx-team and prepare for the patches:
* hg pull fx-team
* hg up fx-team
* hg bookmark fx-team-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all fx-team checkin-needed patches
Verify your outgoing changes:
* hg out -r . fx-team
If you haven't lost a push race:
* hg push -r . fx-team
If you lost a push race:
* hg pull fx-team
* hg rebase -d fx-team
* hg push -r . fx-team
Delete your no longer needed bookmark:
* hg bookmark -d fx-team-checkins

===== Multiple repositories with a single set of patches each =====
You can set up multiple sets of patches at once against multiple repositories:
Update fx-team
* hg pull fx-team && hg up fx-team
Create a bookmark to base your fx-team checkin-needed patches
* hg bookmark fxteam-checkins
Import a bunch of patches against fx-team
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your fx-team checkins and add another patch to the bookmark, then push it
* hg up fxteam-checkins
* hg import <patch5>
* hg out -r . fx-team # this will be patch1, patch2, and patch5
* hg push -r . fx-team
* hg bookmark -d fxteam-checkins

===== Single repository with multiple sets of patches =====
Or have multiple sets of patches against a single repository:
Update fx-team
* hg pull fx-team && hg up fx-team
Make the first bookmark/set
* hg bookmark fxteam-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up fx-team && hg bookmark fxteam-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . fx-team # patch3 and patch4
* hg up fxteam-checkins-1 && hg out -r . fx-team # patch1 and patch2
Push the first set
* hg push -r . fx-team # pushes patch1 and patch2
Get ready to push the second set
* hg up fxteam-checkins-2
* hg rebase -d fx-team # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . fx-team # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d fxteam-checkins-1
* hg bookmark -d fxteam-checkins-2

=== Uplifts ===
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

=== Backouts ===
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* hg backout -r <revision>
** 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).
* hg push -r . <tree>

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can still be used, though you will want to use `hg oops` in place of `hg qbackout` (eg if you use `hg share` to get multiple working directories, qbackout and other uses of mq do not play nice with shared repos):
* Copy the backout <revision> from treeherder
* hg oops -e -r <revision>
** This should open up your editor with a prepopulated commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg out -r . <tree>
** to double-check what you will be pushing
* hg push -r . <tree>

qbackout can also back out a range of commits in a single backout commit:
* hg oops -e -s -r <toprevision>:<bottomrevision>
** This will open your editor with a prepopulated commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg push -r . <tree>
(Omit oops's -s flag to back out each individual revision in the range as a separate commit.)

==== Revert a backout ====
* `hg graft`, see https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

=== Rebasing after losing a push race ===
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

=== Recovering from mistakes ===
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

You may also need to use some combination of the following to get things back to a known-good state:
* hg purge # http://mercurial.selenic.com/wiki/PurgeExtension
* hg up -C

=== See what you're about to push ===
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

=== View incoming changes ===
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

=== See the log for a particular branch ===
* hg log -fr [branch]

= Extras =
== hg aliases ==
=== mergetocentral/mergetointegration ===
I set up the following aliases in my global .hgrc file to make merging things around trunk a little faster:
[alias]
# merge tree $1, revision $2 to central, optionally appending $3 (for "CLOSED TREE", etc)
mergetocentral = !$HG pull central ; $HG up central ; $HG pull $1 ; $HG merge $2 ; $HG commit -m "Merge $1 to central, a=merge $3" ; $HG push -r . central
# merge central tip to tree $1, optionally appending $2 (for "CLOSED TREE", etc)
mergetointegration = !$HG pull central ; $HG pull $1 ; $HG up $1 ; $HG merge central ; $HG commit -m "Merge m-c to $1, a=merge $2" ; $HG push -r . $1

With these set up, I can merge fx-team's revision 04a3d9130aa0 over to mozilla-central with the following command:
hg mergetocentral fx-team 04a3d9130aa0
and then I can merge mozilla-central's tip back to fx-team with the following command:
hg mergetointegration fx-team
This cuts down on a lot of repetitive typing, saving a bit of time.

=== rbimport ===
For merging from reviewboard patches, there's this alias
rbimport = !hg transplant -e -s https://reviewboard-hg.mozilla.org/gecko -b $1

Then, it's matter of importing the right hash like the following command:
hg rbimport dd1462ba321db983061b94e30cee92b6bd81e908

Sheriffing/How To/Trees

2017-07-23T08:19:43Z

KWierso:

What trees do sheriffs monitor?

= Regularly =
* [https://treeherder.mozilla.org/#/jobs?repo=autoland autoland]
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound mozilla-inbound]
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-central mozilla-central]

= As required =
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta mozilla-beta]
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-release mozilla-release]
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr52 mozilla-esr52]

= By request =
* [https://treeherder.mozilla.org/#/jobs?repo=date date]
[[Category:Sheriffing:HowTo]]

Sheriffing/How To/Trees

2017-07-23T08:19:18Z

KWierso: Add category

Category:Sheriffing:HowTo

2017-07-23T08:17:32Z

KWierso: Create page

List of helpful pages for sheriffing.

Sheriffing/How To/Treeherder

2017-07-23T08:14:55Z

KWierso: Categorize page

[[Category:Sheriffing:HowTo]]

Treeherder is the dashboard used by sheriffs and the rest of Mozilla to see build and test results. When you first open [https://treeherder.mozilla.org Treeherder], there will be a lot of information thrown at you all at once. This document should help explain what to do with it all.
[[File:Treeherder_intermittent.png|thumbnail|right|Treeherder interface showing an intermittent failure]]

= Common Terms =
There are a lot of terms used within Mozilla that aren't necessarily common elsewhere.

# '''Repo''' - Shorthand for 'repository', this is where developers push their commits to have them become part of an upcoming version of Firefox. An example of this is the 'mozilla-inbound' repository.
# '''Tree''' - Another term for a repository, in reference to the branched nature of development under version control. 'Treeherder' is based on this, as a tool to "manage the trees".
# '''Job''' - The smallest unit of work shown in Treeherder's main UI. This can be a build job or a test job. Each test job can run many tests within it, but they get reported as a group to Treeherder. Examples of these would be the Windows 8 x64 Debug build job, or a mochitest-browser-chrome-1 test job.

Each push to a repository will run a number of build jobs for various platforms (Linux, MacOS, Windows, Android). Most platforms will make multiple builds in various configurations: OPT (optimized builds that strip out information helpful for debugging failures in favor of making things faster), DEBUG (unoptimized builds that don't strip out the debugging information), and [https://en.m.wikipedia.org/wiki/Profile-guided_optimization PGO] (the build compiler process runs through the code a few times, taking longer to complete, but speeding up some code paths to make the build run faster than Opt builds). Each of those builds will each be used to run some number of test jobs to verify that the compiled code is running as intended. When either a build or test job runs into trouble, the job is reported as a failure to Treeherder, needing to be classified (also called 'starred' at Mozilla. Classifying a job marks the job as classified by adding a star next to the job symbol in Treeherder by the current sheriff on duty (that's you!).

= The Treeherder UI =
== Header ==
At the top of the site's header section are some menus and buttons that can be useful. The 'Infra' menu holds links to a few other Mozilla tools/websites. The 'Repos' menu provides links to view other Mozilla source code repositories within Treeherder. The 'Filters' menu has tools to filter down the jobs shown within Treeherder on various criteria. The '?' menu has various help pages for Treeherder. The 'Login/Register' button lets you log in to Treeherder, allowing you to make changes to/with Treeherder's tools.

The next row in the site header includes a menu showing the currently selected repository, with information about the state of the repository (closed/open/approval-required). The 'Tiers' menu lets you select which [[Sheriffing/Job_Visibility_Policy|tiers]] of jobs are displayed. The 'Excluded Jobs' button toggles whether jobs that have been intentionally hidden from view are shown. The '+' or '-' button toggles whether groups of non-failing jobs are collapsed or expanded. The various colored circle buttons toggle the visibility of jobs in various states (red toggles failing jobs, green toggles passing jobs, etc). The textbox at the end is a quick-filter box, you can filter jobs by various properties from it without constructing a more exact filter from the 'Filters' menu above. Treeherder displays the count of jobs that are currently "unclassified" in the middle of this row. More on this below.

== Main Section ==
Below the site header is the main part of Treeherder. This shows the recent commits to the currently selected repository grouped by the [http://mozilla-version-control-tools.readthedocs.io/en/latest/hgmo/pushlog.html pushes] they were landed in.

The left side of each push shows the commit data for each commit in the push (eg, the commit hash, the commit author, and the commit message). This can be just a single commit or the push could contain up to hundreds of commits. Treeherder caps the view at 20 commits for performance reasons. Click the "... and more" links to view the entire push's contents on hg.mozilla.org.

The right side of each push shows the build and test results for all of the jobs running with this push's commits. This is where most sheriffing work happens, as it is where job failures are reported, and the job failures need to be classified (also referred to as 'starred' in various places).

== Bottom Panel ==

If you select one of the job symbols for a push, a panel at the bottom of the page will open. The panel has a few sections with information about the job.

On the left side of the panel, there are a few buttons that can be clicked to open the log file for the job as well as submit a request for the job to be re-run. Below those buttons is a list of information about the job, like the name of the job, when the job was requested by the build system, when the build system actually started working on the job, and when the job finished being run.

On the right side of the panel are a number tabs with more information about the job. Depending on the state of the job you selected, the tab that gets selected by default will vary. (A green/passing job will default to the 'Job Details' tab, a failing job will default to either the 'Failure Summary' or 'Failure Classification' tabs.)

The 'Job Details' tab lists more detailed information from the job, including all of the files created and uploaded as part of the job running (eg, log files, screenshots of certain failures, etc).

The 'Failure Summary' and 'Failure Classification' tabs show information on a job's reported failures. They both list the same information, but are used slightly differently. 'Failure Summary' handles all failures in a job as a whole, 'Failure Classification' can handle each individual failure within a job on its own, and is part of the Autoclassify system. These views will list each failure line, as well as any bugs from Bugzilla that match (or are at least similar in some way) the reported failure. If you're signed in, you'll also see extra controls for classifying the failures.

The 'Annotations' tab shows any classifications that have already been performed for the job. If you're signed in, you'll also see UI for removing classifications, in the case that something was classified incorrectly and you need to correct it.

=== Pinboard ===

The pinboard is an area where you can add one or more jobs and pair those with related bugs or comments/reasons, before you submit the classifications to the database. Typically you'd use this on a single job at a time, but if multiple jobs are broken for the same reason, e.g:

* a patch broke a test completely, and you need to classify the failed jobs against the push that broke/fixed it
* something in the build infrastructure is broken, causing lots of jobs to fail at once

It can save time to pin them all at once and apply a single classification to them all with a single click. <<pinboard image here>>

== Job Colors ==

Treeherder displays build and test results in different colors, depending on the job status:

* lightgray = pending
* gray = running
* green = success
* orange = tests failed
* purple = infrastructure exception
* red = build error
* blue = build has been restarted
* pink =build was cancelled

See the 'Job Notation' section of the [https://treeherder.mozilla.org/userguide.html Treeherder's User Guide] for more information.

= Useful Shortcuts =

Treeherder has several useful keyboard shortcuts. As Sheriffs these shortcuts are super helpful:

* u = Toggle showing only unclassified failures
* n = Highlight next unclassified failure
* p = Highlight previous unclassified failure
* spacebar = 'Pin' the currently selected job to Treeherder's Pinboard

A typical workflow would be to load Treeherder, hit 'u' to switch to the only-unclassified-failures mode (gets rid of a bunch of passing jobs that we typically have no interest in), then use either 'n' or 'p' to cycle through each failed job, classifying them as we go until all failures have been classified.

An overlay showing all of Treeherder's keyboard shortcuts can be shown by pressing the '?' key on your keyboard while Treeherder is open in your browser. (Note: Not the '?' menu in the site header, although the User Guide does list the shortcuts.)

= Classifying/Starring jobs =

== What does it do? ==
# Submits the failure and classification to [https://brasstacks.mozilla.com/orangefactor/ OrangeFactor]. This dashboard helps track trends in classified failures, so failures that happen frequently (or suddenly start failing frequently) can be prioritized.
# Stores the classification comment and any associated bugs 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 star icon added next to the job symbol), so they know it has been dealt with.

The list of jobs and classifications updates on its own periodically as pushes and job information are reported to Treeherder.

== How are things starred/classified? ==
You first need to sign in to Treeherder to classify failures and have the classifications recorded. Click the "Login/Register" button in the header and follow the login process.

After you're signed in, open [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=67cd1ee26f2661fa5efe3d952485ab3c89af4271&selectedJob=114156916 this page]. It should open up a Treeherder page to a specific push, and will select a specific job. This will open the bottom panel, and one of the Failure tabs will be selected. This example will use the 'Failure Summary' tab, as it is easier to explain to a newcomer than the 'Failure Classification' tab. Click the 'Failure Summary' tab yourself if it isn't already selected. The tab should look something like <<IMAGE GOES HERE>>.

In this example, the job reports three lines of failures. We're only interested in the first line, as the other two lines don't contain any actionable information (<<But why?>>). The first failure consists of the line '''1536 INFO TEST-UNEXPECTED-FAIL | toolkit/components/places/tests/browser/browser_bug248970.js | Check the total items count - Got 17, expected 16'''. From this, there are three pieces of information to consider.
* "TEST-UNEXPECTED-FAIL" is the kind of failure. There can be other failures like "TEST-UNEXPECTED-TIMEOUT" and "PROCESS-CRASH".
* "toolkit/components/places/tests/browser/browser_bug248970.js" is the test file that reported the failure.
* "Check the total items count - Got 17, expected 16" is the error that occurred.

Below the failure line can be one or more bugs from Bugzilla that match up with part or all of the failure line, with the matching portions between the two highlighted in '''bold''' text. In this example, the entire bug summary (except for the added word "Intermittent") is in bold, meaning it matches up exactly with the failure line. Careful, this only matches each individual word from the failure line to each word from the bug summary, so the order of words doesn't matter for highlighting purposes. You'll need to check yourself whether the two actually match for real.

Next to the bug summary is a button with a 'pin' icon. If you click it, the job is added to the pinboard, and the bug number is added to the 'Bugs' section of the pinboard. Once you're confident that the classification is correct, you can click the pinboard's "Save" button to submit the classification to Treeherder's database. If this job isn't already classified, the job symbol will get a star icon added next to it.

That's it! You've classified/starred a job! You can move on to a different failed job.

= More Treeherder Resources =

More information about the Treeherder project can be found [[Auto-tools/Projects/Treeherder|here]].

Platform/Uptime/NightlyCrashAnalysis

2017-07-21T01:11:43Z

KWierso: /* What if a Nightly build is super crashy? */

This is a rough guide on how to analyze the crash reports for a particular day's Nightly build.

== Crash Report Basics ==

The first thing you should do is watch David Baron's
[https://air.mozilla.org/a-talk-about-understanding-crash-reports/ talk about crash reports]. Watch it all the way through. It's full of useful information.

Also, see the [https://developer.mozilla.org/en-US/docs/Understanding_crash_reports documentation about reading individual crash reports] on MDN.

== Nightly Triage ==

The start point is [http://dbaron.org/mozilla/crashes-by-build this page]. You should look at the crashes for all four platforms (Windows, Mac, Linux, Android) for the the build you are analyzing.

We keep notes at [[Platform/Uptime#Notes]]. Please add your notes to the top of that page. You don't need to write a lot. The logs serves two main purposes:
* To show which builds have been analyzed (and any that might have been missed).
* To communicate anything that might be useful to the people coming up in the roster (e.g. if crash reports are currently broken on one platform, or something like that).

Nightly builds are created at 3am California time. It's generally best to wait at least 24 hours before analyzing a build, because that gives enough time for a decent number of crashes to come in.

Windows crash numbers are much higher than the other and you will likely spend most of your time looking at them. Typical numbers for the #1 crash signature on Windows will be anywhere from 10--50 crash reports, though there is plenty of variation from day to day.

The basic goal of triage is to get a sense of the current crash situation and take steps to improve it.
* Look closely at most/all of the top crash signatures (e.g. top 10--15 on Windows, top 5 or so on other platforms). (There are certain ones that are hard to act on, e.g. "ShutdownKill", "OOM | Small", Flash crashes.)
* When appropriate, file bugs for signatures that lack them (more details about this are below). If a signature only has an old bug, filing a new one might be appropriate.
* Check bugs for signatures that have them to see if they need additional information.
* If a bug has been closed but the crash is still happening, the bug might need to be reopened.
* If a bug is open but stalled, adding a NEEDINFO request might help, and adding information about crash frequency can be helpful. (Polite nagging can be effective!)
* Look for distinct crash signatures that might be related, e.g. multiple signatures relating to a11y, or to the JS JITs.
* The lower-ranked signatures are less important, though filing bugs for signatures that lack them can still be useful.

One caveat is that sometimes multiple crashes (possibly even 10s or 100s) with a particular signature all come from a single installation. Those ones are usually best ignored, because it's difficult to tell if it's a real problem or a problem with the user's machine or installation, and there are enough other crashes to deal with. Likewise, if a crash appears on one Nightly build but none before or after, it's probably not worth filing.

To determine how many installations a particular crash signature has affected:
* Look at the "Product*" box, which has an "installations" column. Note that this box gives results for the past 7 days, unlike the other boxes.
* Add the "install time" field to the search box in a signature report. If the install times are all identical it's almost certainly a single installation.

JS engine crashes can be difficult to deal with, especially those involving the JITs and the GC, because crashes with different causes can get lumped into the same signature.

== Filing Bug Reports ==

To file a bug report about a particular crash signature, view one crash report and use the relevant "Report this bug in" link. This pre-populates the bug report with the "crash" keyword and a link to the particular crash report.

When you file a bug report, things to mention include the following.
* The signature and the crash reason (or pattern of crash reasons)
* The Nightly build id, which looks like "20160506052823".
* How many crashes have occurred with this signature.
* Anything unusual (crash only on specific platforms, only in certain locales or on certain sites, extension or dll correlations of interest, whether it's a startup crash, etc.) The correlations tab in crash-stats is great for this.
* The rank (e.g. "this is the #1 top crash for Nightly 20160506052823").
* How many installations are involved.
* If the signature is new, and if so, which Nightly build it started in. One way to determine this is to modify the search parameters (by modifying the URL, or by modifying the search in the crash-stats UI) to broaden the search, e.g. by removing the particular Nightly build identifier and changing the date parameters.
* If possible, a regression window for that Nightly. You can get regression Windows by using the "Choose regression window" button on the [http://dbaron.org/mozilla/crashes-by-build start page].
* If possible, an indication of which bug's patches may have caused the crash.

Don't worry too much if you can't get all of these things. Getting the right person to look at a crash report is the most important thing. Therefore, you should always NEEDINFO someone in a bug report. If you look at the top few frames of one or more reports, try to see if there are any lines that changed recently. If so, that's a good clue as to what change caused the crash and you can NEEDINFO the author. Failing that, NEEDINFO someone appropriate based on your knowledge of the codebase, or by looking at who has modified nearby lines, or by consulting the [[Modules/All|module owners]] or [[Bugmasters/Project/Bug_Handling/Triage_Leads|triage leads]] lists.

Sometimes a single crash cause will result in multiple signatures. It's useful to link all the relevant signatures to the same bug. {{Bug|1229252}} is a good example, where the "crash signature" field grew steadily over a period of weeks.

A crash that occurs more than 10 times a day, across multiple installations, is probably impactful enough to be worth tracking. Set the appropriate tracking flag to '?' in the bug report, so that release drivers will be aware of it.

When you file a new bug for a crash signature, that bug won't show up in the "Bugs" columns of crash-stats for a few hours. Which is a shame, because it would be nice to double-check the linking immediately, but it's understandable that crash-stats doesn't ping Bugzilla all the time.

== What if a Nightly build is super crashy? ==

Occasionally a Nightly build is super crashy. When this happens, there are a few things to be done:
* First, tell an appropriate person (ping in #releng or maybe #moc ) so that updates can be stopped as soon as possible. A tracking bug (Release Engineering :: General) should be filed at this point by someone (you or the person stopping updates).
* Second, if the regressing patch can be identified and backed out, ask an appropriate person to "respin" Nightly, i.e. rebuild and re-release it. This takes a couple of hours, so is only worthwhile if the next day's Nightly build is still some time off. An "appropriate person" for this can be found by broadcasting to one of the #sheriffs, #taskcluster or #releng IRC channels, or by emailing the sheriffs [https://mail.mozilla.org/listinfo/sheriffs mailing list].
* Finally, once the issue has been resolved and new Nightly builds are ready to go out to users, contact the person who froze updates in step 1 so that updates can be unfrozen.

== Miscellaneous ==

At the end of each development cycle, it's worth paying attention to which crashes affect both Nightly and Beta, and therefore have fixes that need uplift to Beta.

Sheriffing/How To/Getting started as a sheriff

2017-07-14T22:57:37Z

KWierso: /* Sheriffed Repositories */

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

= Things You'll Need =

Not all of these have to be ready on Day One, but eventually you'll need the following.
* [[IRC|IRC account]], for communicating with developers, fellow sheriffs, and others.
* [[Sheriffing/How:To:SheriffingFromUnifiedRepos#Setting_up_the_repo|Clone of the Mercurial repositories]], for committing changes to the repositories.
* A properly configured mercurial setup. You can use `./mach mercurial-setup` from your clone of the repository to run through a setup wizard. I recommend setting up the qbackout extension to aid in easily backing out patches.
* LDAP account, for signing in to Treeherder and pushing commits to the source code repositories.
* [https://www.mozilla.org/en-US/firefox/new/ A modern browser], to access [[Sheriffing/How:To:Treeherder|Treeherder]], [https://bugzilla.mozilla.org Bugzilla], and other Mozilla web tools.

= The Sheriffs How-To =

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

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

= Communication =

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

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

A more-complete list of channels is listed [[IRC#Commonly_Used_Mozilla_IRC_Channels|here]].

= Sheriffed Repositories =

Mozilla has dozens of different source code repositories for various projects and releases, but sheriffs only need to care about a few of them:
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-central mozilla-central], the main development repository.
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound mozilla-inbound], one of mozilla-central's integration branches where new commits initially land for testing.
* [https://treeherder.mozilla.org/#/jobs?repo=autoland autoland], another integration branch for mozilla-central.
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta mozilla-beta], one of the release stabilization branches for code that has already gone through several weeks of testing.
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-release mozilla-release], the official release branch, where Firefox code goes to become part of an official build of Firefox.
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr52 mozilla-esrXX], one or more branches set up to track patches for the current (and at times when the ESR releases overlap, the previous) version of [https://www.mozilla.org/en-US/firefox/organizations/ Firefox ESR]. (At the moment, this is mozilla-esr52.)

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

= Sheriffing Tasks =

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

Sheriffing/How To/Getting started as a sheriff

2017-07-14T22:21:58Z

KWierso: Initial page

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

= Things You'll Need =

Not all of these have to be ready on Day One, but eventually you'll need the following.
* [[IRC|IRC account]], for communicating with developers, fellow sheriffs, and others.
* [[Sheriffing/How:To:SheriffingFromUnifiedRepos#Setting_up_the_repo|Clone of the Mercurial repositories]], for committing changes to the repositories.
* A properly configured mercurial setup. You can use `./mach mercurial-setup` from your clone of the repository to run through a setup wizard. I recommend setting up the qbackout extension to aid in easily backing out patches.
* LDAP account, for signing in to Treeherder and pushing commits to the source code repositories.
* [https://www.mozilla.org/en-US/firefox/new/ A modern browser], to access [[Sheriffing/How:To:Treeherder|Treeherder]], [https://bugzilla.mozilla.org Bugzilla], and other Mozilla web tools.

= The Sheriffs How-To =

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

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

= Communication =

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

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

A more-complete list of channels is listed [[IRC#Commonly_Used_Mozilla_IRC_Channels|here]].

= Sheriffed Repositories =

Mozilla has many dozens of different source code repositories for various projects and releases, but sheriffs only need to care about a few of them:
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-central mozilla-central], the main development repository.
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound mozilla-inbound], one of mozilla-central's integration branches where new commits initially land for testing.
* [https://treeherder.mozilla.org/#/jobs?repo=autoland autoland], another integration branch for mozilla-central.
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta mozilla-beta], one of the release stabilization branches for code that has already gone through several weeks of testing.
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-release mozilla-release], the official release branch, where Firefox code goes to become part of an official build of Firefox.
* [https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr52 mozilla-esrXX], one or more branches set up to track patches for the current (and at times when the ESR releases overlap, the previous) version of [https://www.mozilla.org/en-US/firefox/organizations/ Firefox ESR]. (At the moment, this is mozilla-esr52.)

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

= Sheriffing Tasks =

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

Sheriffing/How:To

2017-07-14T22:19:49Z

KWierso: Add Bootstrap page

= Sheriff How-To / Knowledge Share =

== B ==
*[[Sheriffing/How:To:Backouts|Backouts]]
*[[Sheriffing/How:To:Bisecting |Bisecting]]
*[[Sheriffing/How:To:Bootstrap| Sheriffing Bootstrap]]

== C ==
* [[Sheriffing/How:To:Community_Sheriffs|Community_Sheriffs and you - also current issues]]

== D ==
* [[Sheriffing/How:To:DayOne|Sheriffing Day - One]]
* [[Sheriffing/Deciding_To_Close_A_Tree|Deciding to Close A_Tree & Actions]]

== E ==
* [[Sheriffing/How:To:Escalate|Escalating issues to MOC or Releng]]

== H ==
* [[Sheriffing/How:To:Hangs|Hangs/Timeout Failures]]

== I ==
* [[Sheriffing/How:To:Intermittent-bugs| How to file a Intermittent failure]]

== L ==
* [[Sheriffing/How:To:Landing_checkin-needed_patches|Landing checkin-needed patches]]

== M ==
* [[Sheriffing/How:To:Merges|Merges]]
* [[Sheriffing/How:To:Merge_Conflicts|Merge Conflicts]]

== R ==
* [[Sheriffing/How:To:Restarts|Retrigger (Restart)]]
* [[Sheriffing/How:To:Retrigger_PGO_Builds|Retrigger PGO/Nightlies]]

== S ==
* [[Sheriffing/How:To:Sheriffs-Schedule| Sheriffing Schedule]]

== T ==
* [[Sheriffing/How:To:Treeherder|Treeherder]]
* [[Sheriffing/How:To:Trees|Trees]]

== U ==
* [[Sheriffing/How:To:Uplifts|Uplifts]]
* [[Sheriffing/How:To:SheriffingFromUnifiedRepos|SheriffingFromUnifiedRepos]]

Sheriffing/How:To

2017-07-14T21:57:28Z

KWierso: Switch a TBPL link for a Treeherder link

= Sheriff How-To / Knowledge Share =

== B ==
*[[Sheriffing/How:To:Backouts|Backouts]]
*[[Sheriffing/How:To:Bisecting |Bisecting]]

== C ==
* [[Sheriffing/How:To:Community_Sheriffs|Community_Sheriffs and you - also current issues]]

== D ==
* [[Sheriffing/How:To:DayOne|Sheriffing Day - One]]
* [[Sheriffing/Deciding_To_Close_A_Tree|Deciding to Close A_Tree & Actions]]

== E ==
* [[Sheriffing/How:To:Escalate|Escalating issues to MOC or Releng]]

== H ==
* [[Sheriffing/How:To:Hangs|Hangs/Timeout Failures]]

== I ==
* [[Sheriffing/How:To:Intermittent-bugs| How to file a Intermittent failure]]

== L ==
* [[Sheriffing/How:To:Landing_checkin-needed_patches|Landing checkin-needed patches]]

== M ==
* [[Sheriffing/How:To:Merges|Merges]]
* [[Sheriffing/How:To:Merge_Conflicts|Merge Conflicts]]

== R ==
* [[Sheriffing/How:To:Restarts|Retrigger (Restart)]]
* [[Sheriffing/How:To:Retrigger_PGO_Builds|Retrigger PGO/Nightlies]]

== S ==
* [[Sheriffing/How:To:Sheriffs-Schedule| Sheriffing Schedule]]

== T ==
* [[Sheriffing/How:To:Treeherder|Treeherder]]
* [[Sheriffing/How:To:Trees|Trees]]

== U ==
* [[Sheriffing/How:To:Uplifts|Uplifts]]
* [[Sheriffing/How:To:SheriffingFromUnifiedRepos|SheriffingFromUnifiedRepos]]

Sheriffing/How To/Treeherder

2017-07-14T07:58:17Z

KWierso: More terms

WIP

Treeherder is the dashboard used by sheriffs and the rest of Mozilla to see build and test results. When you first open [https://treeherder.mozilla.org Treeherder], there will be a lot of information thrown at you all at once. This document should help explain what to do with it all.
<<TREEHERDER LANDING IMAGE>>

= Common Terms =

There are a lot of terms used within Mozilla that aren't necessarily common elsewhere.

# Repo - Shorthand for 'repository', this is where developers push their commits to have them become part of an upcoming version of Firefox. An example of this is the 'mozilla-inbound' repository.
# Tree - Another term for a repository. 'Treeherder' is based on this, as a tool to "manage the trees".
# Job - The smallest unit of work shown in Treeherder's main UI. This can be a build job or a test job. Each test job can run many tests within it, but they get reported as a group to Treeherder. Examples of these would be the Windows 8 x64 Debug build job, or a mochitest-browser-chrome-1 test job.

Each push to a repository will run a number of build jobs for various platforms (Linux, MacOS, Windows, Android). Most platforms will make multiple builds in various configurations: OPT (optimized builds that strip out information helpful for debugging failures in favor of making things faster), DEBUG (unoptimized builds that don't strip out the debugging information), and [https://en.m.wikipedia.org/wiki/Profile-guided_optimization PGO] (the build compiler process runs through the code a few times, taking longer to complete, but speeding up some code paths to make the build run faster than Opt builds). Then those builds will each be used to run a number of test jobs to verify that the compiled code is running as intended. Then either a build or test job runs into trouble, the job is reported as a failure to Treeherder, needing to be classified (also called 'starred' at Mozilla, since classifying a job marks the job as classified by adding a star next to the job symbol in Treeherder by the current sheriff on duty (that's you!).

= Treeherder's UI =

== Header ==
At the top of the site's header section are some menus and buttons that can be useful. The 'Infra' menu holds links to a few other Mozilla tools/websites. The 'Repos' menu provides links to view other Mozilla source code repositories within Treeherder. The 'Filters' menu has tools to filter down the jobs shown within Treeherder on various criteria. The '?' menu has various help pages for Treeherder. The 'Login/Register' button lets you log in to Treeherder, allowing you to make changes to/with Treeherder's tools.

The next row in the site header includes a menu showing the currently selected repository, with information about the state of the repository (closed/open/approval-required). The 'Tiers' menu lets you select which [[Sheriffing/Job_Visibility_Policy|tiers]] of jobs are displayed. The 'Excluded Jobs' button toggles whether jobs that have been intentionally hidden from view are shown. The '+' or '-' button toggles whether groups of non-failing jobs are collapsed or expanded. The various colored circle buttons toggle the visibility of jobs in various states (red toggles failing jobs, green toggles passing jobs, etc). The textbox at the end is a quick-filter box, you can filter jobs by various properties from it without constructing a more exact filter from the 'Filters' menu above. (Treeherder displays the count of jobs that are currently "unclassified" in the middle of this row. More on this below.)

== Main Section ==

Below the site header is the main part of Treeherder. This shows the recent commits to the currently selected repository grouped by the [http://mozilla-version-control-tools.readthedocs.io/en/latest/hgmo/pushlog.html pushes] they were landed in.

The left side of each push shows the commit data for each commit in the push (eg, the commit hash, the commit author, and the commit message). This can be just a single commit or the push could contain up to hundreds of commits. (Treeherder caps the view at 20 commits for performance reasons. Click the "... and more" links to view the entire push's contents on hg.mozilla.org.)

The right side of each push shows the build and test results for all of the jobs running with this push's commits. This is where most sheriffing work happens, as it is where job failures are reported, and the job failures need to be classified (also referred to as 'starred' in various places).

== Bottom Panel ==

If you select one of the job symbols for a push, a panel at the bottom of the page will open. <<BOTTOM PANEL IMAGE>> The panel has a few sections with information about the job.

On the left side of the panel, there are a few buttons that can be clicked to open the log file for the job as well as submit a request for the job to be re-run. Below those buttons is a list of information about the job, like the name of the job, when the job was requested by the build system, when the build system actually started working on the job, and when the job finished being run.

On the right side of the panel are a number tabs with more information about the job. Depending on the state of the job you selected, the tab that gets selected by default will vary. (A green/passing job will default to the 'Job Details' tab, a failing job will default to either the 'Failure Summary' or 'Failure Classification' tabs.)

The 'Job Details' tab lists more detailed information from the job, including all of the files created and uploaded as part of the job running (eg, log files, screenshots of certain failures, etc).

The 'Failure Summary' and 'Failure Classification' tabs show information a job's reported failures. They both list the same information, but are used slightly differently ('Failure Summary' handles all failures in a job as a whole, 'Failure Classification' can handle each individual failure within a job on its own, and is part of the Autoclassify system.) These views will list each failure line, as well as any bugs from Bugzilla that match (or are at least similar in some way) the reported failure. If you're signed in, you'll also see extra controls for classifying the failures.

The 'Annotations' tab shows any classifications that have already been performed for the job. If you're signed in, you'll also see UI for removing classifications, in the case that something was classified incorrectly and you need to correct it.

=== Pinboard ===

The pinboard is an area where you can add one or more jobs and pair those with related bugs or comments/reasons, before you submit the classifications to the database. Typically you'd use this on a single job at a time, but if multiple jobs are broken for the same reason (a patch broke a test completely, and you need to classify the failed jobs against the push that broke/fixed it, something in the build infrastructure is broken, causing lots of jobs to fail at once, etc), it can save time to pin them all at once and apply a single classification to them all with a single click. <<pinboard image here>>

== Job Colors ==

Treeherder displays build and test results in different colors, depending on the job status:

* lightgray = pending
* gray = running
* green = success
* orange = tests failed
* purple = infrastructure exception
* red = build error
* blue = build has been restarted
* pink =build was cancelled

See the 'Job Notation' section of the [https://treeherder.mozilla.org/userguide.html Treeherder's User Guide] for more information.

= Useful Shortcuts =

Treeherder has several useful keyboard shortcuts. As Sheriffs these shortcuts are super helpful:

* u = Toggle showing only unclassified failures
* n = Highlight next unclassified failure
* p = Highlight previous unclassified failure
* spacebar = 'Pin' the currently selected job to Treeherder's Pinboard

A typical workflow would be to load Treeherder, hit 'u' to switch to the only-unclassified-failures mode (gets rid of a bunch of passing jobs that we typically have no interest in), then use either 'n' or 'p' to cycle through each failed job, classifying them as we go until all failures have been classified.

An overlay showing all of Treeherder's keyboard shortcuts can be shown by pressing the '?' key on your keyboard while Treeherder is open in your browser. (Note: Not the '?' menu in the site header, although the User Guide does list the shortcuts.)

= Classifying/Starring jobs =

== What does it do? ==

# Submits the failure and classification to [https://brasstacks.mozilla.com/orangefactor/ OrangeFactor]. This dashboard helps track trends in classified failures, so failures that happen frequently (or suddenly start failing frequently) can be prioritized.
# Stores the classification comment and any associated bugs 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 star icon added next to the job symbol), so they know it has been dealt with.

The list of jobs and clasifications updates on its own periodically as pushes and job information are reported to Treeherder.

== How are things starred/classified? ==

You first need to sign in to Treeherder to classify failures and have the classifications recorded. Click the "Login/Register" button in the header and follow the login process.

After you're signed in, open [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=67cd1ee26f2661fa5efe3d952485ab3c89af4271&selectedJob=114156916 this page]. It should open up a Treeherder page to a specific push, and will select a specific job. This will open the bottom panel, and one of the Failure tabs will be selected. This example will use the 'Failure Summary' tab, as it is easier to explain to a newcomer than the 'Failure Classification' tab. Click the 'Failure Summary' tab yourself if it isn't already selected. The tab should look something like <<IMAGE GOES HERE>>.

In this example, the job reports three lines of failures. We're only interested in the first line, as the other two lines don't contain any actionable information (<<But why?>>). The first failure consists of the line '''1536 INFO TEST-UNEXPECTED-FAIL | toolkit/components/places/tests/browser/browser_bug248970.js | Check the total items count - Got 17, expected 16'''. From this, there are three pieces of information to consider.
* "TEST-UNEXPECTED-FAIL" is the kind of failure. There can be other failures like "TEST-UNEXPECTED-TIMEOUT" and "PROCESS-CRASH".
* "toolkit/components/places/tests/browser/browser_bug248970.js" is the test file that reported the failure.
* "Check the total items count - Got 17, expected 16" is the error that occurred.

Below the failure line can be one or more bugs from Bugzilla that match up with part or all of the failure line, with the matching portions between the two highlighted in '''bold''' text. In this example, the entire bug summary (except for the added word "Intermittent") is in bold, meaning it matches up exactly with the failure line. (Careful, this only matches each individual word from the failure line to each word from the bug summary, so the order of words doesn't matter for highlighting purposes. You'll need to check yourself whether the two actually match for real.)

Next to the bug summary is a button with a 'pin' icon. If you click it, the job is added to the pinboard, and the bug number is added to the 'Bugs' section of the pinboard. Once you're confident that the classification is correct, you can click the pinboard's "Save" button to submit the classification to Treeherder's database. If this job isn't already classified, the job symbol will get a star icon added next to it.

That's it! You've classified/starred a job! You can move on to a different failed job.

= More Treeherder Resources =

More information about the Treeherder project can be found [[Auto-tools/Projects/Treeherder|here]].

Sheriffing/How To/Treeherder

2017-07-14T07:49:57Z

KWierso: Add some helpful terms

WIP

Treeherder is the dashboard used by sheriffs and the rest of Mozilla to see build and test results. When you first open [https://treeherder.mozilla.org Treeherder], there will be a lot of information thrown at you all at once. This document should help explain what to do with it all.
<<TREEHERDER LANDING IMAGE>>

= Common Terms =

There are a lot of terms used within Mozilla that aren't necessarily common elsewhere.

# Repo - Shorthand for 'repository', this is where developers push their commits to have them become part of an upcoming version of Firefox. An example of this is the 'mozilla-inbound' repository.
# Tree - Another term for a repository. 'Treeherder' is based on this, as a tool to "manage the trees".
# Job - The smallest unit of work shown in Treeherder's main UI. This can be a build job or a test job. Each test job can run many tests within it, but they get reported as a group to Treeherder. Examples of these would be the Windows 8 x64 Debug build job, or a mochitest-browser-chrome-1 test job. Each push to a repository will run a number of build jobs for various platforms (Linux, MacOS, Windows, Android). Most platforms will make builds in various configurations: OPT (optimized builds that strip out information helpful for debugging failures), DEBUG (unoptimized builds that don't strip out the debugging information), and PGO (the build process runs a few times, taking longer to complete, but speeding up some code paths to make the build run faster) then those builds will each be used to run a number of test jobs in.

= Treeherder's UI =

== Header ==
At the top of the site's header section are some menus and buttons that can be useful. The 'Infra' menu holds links to a few other Mozilla tools/websites. The 'Repos' menu provides links to view other Mozilla source code repositories within Treeherder. The 'Filters' menu has tools to filter down the jobs shown within Treeherder on various criteria. The '?' menu has various help pages for Treeherder. The 'Login/Register' button lets you log in to Treeherder, allowing you to make changes to/with Treeherder's tools.

The next row in the site header includes a menu showing the currently selected repository, with information about the state of the repository (closed/open/approval-required). The 'Tiers' menu lets you select which [[Sheriffing/Job_Visibility_Policy|tiers]] of jobs are displayed. The 'Excluded Jobs' button toggles whether jobs that have been intentionally hidden from view are shown. The '+' or '-' button toggles whether groups of non-failing jobs are collapsed or expanded. The various colored circle buttons toggle the visibility of jobs in various states (red toggles failing jobs, green toggles passing jobs, etc). The textbox at the end is a quick-filter box, you can filter jobs by various properties from it without constructing a more exact filter from the 'Filters' menu above. (Treeherder displays the count of jobs that are currently "unclassified" in the middle of this row. More on this below.)

== Main Section ==

Below the site header is the main part of Treeherder. This shows the recent commits to the currently selected repository grouped by the [http://mozilla-version-control-tools.readthedocs.io/en/latest/hgmo/pushlog.html pushes] they were landed in.

The left side of each push shows the commit data for each commit in the push (eg, the commit hash, the commit author, and the commit message). This can be just a single commit or the push could contain up to hundreds of commits. (Treeherder caps the view at 20 commits for performance reasons. Click the "... and more" links to view the entire push's contents on hg.mozilla.org.)

The right side of each push shows the build and test results for all of the jobs running with this push's commits. This is where most sheriffing work happens, as it is where job failures are reported, and the job failures need to be classified (also referred to as 'starred' in various places).

== Bottom Panel ==

If you select one of the job symbols for a push, a panel at the bottom of the page will open. <<BOTTOM PANEL IMAGE>> The panel has a few sections with information about the job.

On the left side of the panel, there are a few buttons that can be clicked to open the log file for the job as well as submit a request for the job to be re-run. Below those buttons is a list of information about the job, like the name of the job, when the job was requested by the build system, when the build system actually started working on the job, and when the job finished being run.

On the right side of the panel are a number tabs with more information about the job. Depending on the state of the job you selected, the tab that gets selected by default will vary. (A green/passing job will default to the 'Job Details' tab, a failing job will default to either the 'Failure Summary' or 'Failure Classification' tabs.)

The 'Job Details' tab lists more detailed information from the job, including all of the files created and uploaded as part of the job running (eg, log files, screenshots of certain failures, etc).

The 'Failure Summary' and 'Failure Classification' tabs show information a job's reported failures. They both list the same information, but are used slightly differently ('Failure Summary' handles all failures in a job as a whole, 'Failure Classification' can handle each individual failure within a job on its own, and is part of the Autoclassify system.) These views will list each failure line, as well as any bugs from Bugzilla that match (or are at least similar in some way) the reported failure. If you're signed in, you'll also see extra controls for classifying the failures.

The 'Annotations' tab shows any classifications that have already been performed for the job. If you're signed in, you'll also see UI for removing classifications, in the case that something was classified incorrectly and you need to correct it.

=== Pinboard ===

The pinboard is an area where you can add one or more jobs and pair those with related bugs or comments/reasons, before you submit the classifications to the database. Typically you'd use this on a single job at a time, but if multiple jobs are broken for the same reason (a patch broke a test completely, and you need to classify the failed jobs against the push that broke/fixed it, something in the build infrastructure is broken, causing lots of jobs to fail at once, etc), it can save time to pin them all at once and apply a single classification to them all with a single click. <<pinboard image here>>

== Job Colors ==

Treeherder displays build and test results in different colors, depending on the job status:

* lightgray = pending
* gray = running
* green = success
* orange = tests failed
* purple = infrastructure exception
* red = build error
* blue = build has been restarted
* pink =build was cancelled

See the 'Job Notation' section of the [https://treeherder.mozilla.org/userguide.html Treeherder's User Guide] for more information.

= Useful Shortcuts =

Treeherder has several useful keyboard shortcuts. As Sheriffs these shortcuts are super helpful:

* u = Toggle showing only unclassified failures
* n = Highlight next unclassified failure
* p = Highlight previous unclassified failure
* spacebar = 'Pin' the currently selected job to Treeherder's Pinboard

A typical workflow would be to load Treeherder, hit 'u' to switch to the only-unclassified-failures mode (gets rid of a bunch of passing jobs that we typically have no interest in), then use either 'n' or 'p' to cycle through each failed job, classifying them as we go until all failures have been classified.

An overlay showing all of Treeherder's keyboard shortcuts can be shown by pressing the '?' key on your keyboard while Treeherder is open in your browser. (Note: Not the '?' menu in the site header, although the User Guide does list the shortcuts.)

= Classifying/Starring jobs =

== What does it do? ==

# Submits the failure and classification to [https://brasstacks.mozilla.com/orangefactor/ OrangeFactor]. This dashboard helps track trends in classified failures, so failures that happen frequently (or suddenly start failing frequently) can be prioritized.
# Stores the classification comment and any associated bugs 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 star icon added next to the job symbol), so they know it has been dealt with.

The list of jobs and clasifications updates on its own periodically as pushes and job information are reported to Treeherder.

== How are things starred/classified? ==

You first need to sign in to Treeherder to classify failures and have the classifications recorded. Click the "Login/Register" button in the header and follow the login process.

After you're signed in, open [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=67cd1ee26f2661fa5efe3d952485ab3c89af4271&selectedJob=114156916 this page]. It should open up a Treeherder page to a specific push, and will select a specific job. This will open the bottom panel, and one of the Failure tabs will be selected. This example will use the 'Failure Summary' tab, as it is easier to explain to a newcomer than the 'Failure Classification' tab. Click the 'Failure Summary' tab yourself if it isn't already selected. The tab should look something like <<IMAGE GOES HERE>>.

In this example, the job reports three lines of failures. We're only interested in the first line, as the other two lines don't contain any actionable information (<<But why?>>). The first failure consists of the line '''1536 INFO TEST-UNEXPECTED-FAIL | toolkit/components/places/tests/browser/browser_bug248970.js | Check the total items count - Got 17, expected 16'''. From this, there are three pieces of information to consider.
* "TEST-UNEXPECTED-FAIL" is the kind of failure. There can be other failures like "TEST-UNEXPECTED-TIMEOUT" and "PROCESS-CRASH".
* "toolkit/components/places/tests/browser/browser_bug248970.js" is the test file that reported the failure.
* "Check the total items count - Got 17, expected 16" is the error that occurred.

Below the failure line can be one or more bugs from Bugzilla that match up with part or all of the failure line, with the matching portions between the two highlighted in '''bold''' text. In this example, the entire bug summary (except for the added word "Intermittent") is in bold, meaning it matches up exactly with the failure line. (Careful, this only matches each individual word from the failure line to each word from the bug summary, so the order of words doesn't matter for highlighting purposes. You'll need to check yourself whether the two actually match for real.)

Next to the bug summary is a button with a 'pin' icon. If you click it, the job is added to the pinboard, and the bug number is added to the 'Bugs' section of the pinboard. Once you're confident that the classification is correct, you can click the pinboard's "Save" button to submit the classification to Treeherder's database. If this job isn't already classified, the job symbol will get a star icon added next to it.

That's it! You've classified/starred a job! You can move on to a different failed job.

= More Treeherder Resources =

More information about the Treeherder project can be found [[Auto-tools/Projects/Treeherder|here]].

Sheriffing/How To/Treeherder

2017-07-14T01:27:22Z

KWierso: Flesh it out

WIP

Treeherder is the dashboard used by sheriffs and the rest of Mozilla to see build and test results. When you first open [https://treeherder.mozilla.org Treeherder], there will be a lot of information thrown at you all at once. This document should help explain what to do with it all.
<<TREEHERDER LANDING IMAGE>>
= Treeherder's UI =

== Header ==
At the top of the site's header section are some menus and buttons that can be useful. The 'Infra' menu holds links to a few other Mozilla tools/websites. The 'Repos' menu provides links to view other Mozilla source code repositories within Treeherder. The 'Filters' menu has tools to filter down the jobs shown within Treeherder on various criteria. The '?' menu has various help pages for Treeherder. The 'Login/Register' button lets you log in to Treeherder, allowing you to make changes to/with Treeherder's tools.

The next row in the site header includes a menu showing the currently selected repository, with information about the state of the repository (closed/open/approval-required). The 'Tiers' menu lets you select which [[Sheriffing/Job_Visibility_Policy|tiers]] of jobs are displayed. The 'Excluded Jobs' button toggles whether jobs that are intentionally hidden from view are shown. The '+' or '-' button toggles whether groups of non-failing jobs are collapsed or expanded. The various colored circle buttons toggle the visibility of jobs in various states (red toggles failing jobs, green toggles passing jobs, etc). The textbox at the end is a quick-filter box, you can filter jobs by various properties from it without constructing a more exact filter from the 'Filters' menu above. (Treeherder displays the count of jobs that are currently "unclassified" in the middle of this row. More on this below.)

== Main Section ==

Below the site header is the main part of Treeherder. This shows the recent commits to the currently selected repository grouped by the [http://mozilla-version-control-tools.readthedocs.io/en/latest/hgmo/pushlog.html pushes] they were landed in.

The left side of each push shows the commit data for each commit in the push (eg, the commit hash, the commit author, and the commit message). This can be just a single commit or the push could contain up to hundreds of commits. (Treeherder caps the view at 20 commits for performance reasons. Click the "... and more" links to view the entire push's contents on hg.mozilla.org.)

The right side of each push shows the build and test results for all of the jobs running with this push's commits. This is where most sheriffing work happens, as it is where job failures are reported, and the job failures need to be classified (also referred to as 'starred' in various places).

== Bottom Panel ==

If you select one of the job symbols for a push, a panel at the bottom of the page will open. <<BOTTOM PANEL IMAGE>> The panel has a few sections with information about the job.

On the left side of the panel, there are a few buttons that can be clicked to open the log file for the job as well as submit a request for the job to be re-run. Below those buttons is a list of information about the job, like the name of the job, when the job was requested by the build system, when the build system actually started working on the job, and when the job finished being run.

On the right side of the panel are a number tabs with more information about the job. Depending on the state of the job you selected, the tab that gets selected by default will vary. (A green/passing job will default to the 'Job Details' tab, a failing job will default to either the 'Failure Summary' or 'Failure Classification' tabs.)

The 'Job Details' tab lists more detailed information from the job, including all of the files created and uploaded as part of the job running (eg, log files, screenshots of certain failures, etc).

The 'Failure Summary' and 'Failure Classification' tabs show information a job's reported failures. They both list the same information, but are used slightly differently ('Failure Summary' handles all failures in a job as a whole, 'Failure Classification' can handle each individual failure within a job on its own, and is part of the Autoclassify system.) These views will list each failure line, as well as any bugs from Bugzilla that match (or are at least similar in some way) the reported failure. If you're signed in, you'll also see extra controls for classifying the failures.

The 'Annotations' tab shows any classifications that have already been performed for the job. If you're signed in, you'll also see UI for removing classifications, in the case that something was classified incorrectly and you need to correct it.

=== Pinboard ===

The pinboard is an area where you can add one or more jobs and pair those with related bugs or comments/reasons, before you submit the classifications to the database. Typically you'd use this on a single job at a time, but if multiple jobs are broken for the same reason (a patch broke a test completely, and you need to classify the failed jobs against the push that broke/fixed it, something in the build infrastructure is broken, causing lots of jobs to fail at once, etc), it can save time to pin them all at once and apply a single classification to them all with a single click. <<pinboard image here>>

== Job Colors ==

Treeherder displays build and test results in different colors, depending on the job status:

* lightgray = pending
* gray = running
* green = success
* orange = tests failed
* purple = infrastructure exception
* red = build error
* blue = build has been restarted
* pink =build was cancelled

See the 'Job Notation' section of the [https://treeherder.mozilla.org/userguide.html Treeherder's User Guide] for more information.

= Useful Shortcuts =

Treeherder has several useful keyboard shortcuts. As Sheriffs these shortcuts are super helpful:

* u = Toggle showing only unclassified failures
* n = Highlight next unclassified failure
* p = Highlight previous unclassified failure
* spacebar = 'Pin' the currently selected job to Treeherder's Pinboard

A typical workflow would be to load Treeherder, hit 'u' to switch to the only-unclassified-failures mode (gets rid of a bunch of passing jobs that we typically have no interest in), then use either 'n' or 'p' to cycle through each failed job, classifying them as we go until all failures have been classified.

An overlay showing all of Treeherder's keyboard shortcuts can be shown by pressing the '?' key on your keyboard while Treeherder is open in your browser. (Note: Not the '?' menu in the site header, although the User Guide does list the shortcuts.)

= Classifying/Starring jobs =

== What does it do? ==

# Submits the failure and classification to [https://brasstacks.mozilla.com/orangefactor/ OrangeFactor]. This dashboard helps track trends in classified failures, so failures that happen frequently (or suddenly start failing frequently) can be prioritized.
# Stores the classification comment and any associated bugs 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 star icon added next to the job symbol), so they know it has been dealt with.

The list of jobs and clasifications updates on its own periodically as pushes and job information are reported to Treeherder.

== How are things starred/classified? ==

You first need to sign in to Treeherder to classify failures and have the classifications recorded. Click the "Login/Register" button in the header and follow the login process.

After you're signed in, open [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=67cd1ee26f2661fa5efe3d952485ab3c89af4271&selectedJob=114156916 this page]. It should open up a Treeherder page to a specific push, and will select a specific job. This will open the bottom panel, and one of the Failure tabs will be selected. This example will use the 'Failure Summary' tab, as it is easier to explain to a newcomer than the 'Failure Classification' tab. Click the 'Failure Summary' tab yourself if it isn't already selected. The tab should look something like <<IMAGE GOES HERE>>.

In this example, the job reports three lines of failures. We're only interested in the first line, as the other two lines don't contain any actionable information (<<But why?>>). The first failure consists of the line '''1536 INFO TEST-UNEXPECTED-FAIL | toolkit/components/places/tests/browser/browser_bug248970.js | Check the total items count - Got 17, expected 16'''. From this, there are three pieces of information to consider.
* "TEST-UNEXPECTED-FAIL" is the kind of failure. There can be other failures like "TEST-UNEXPECTED-TIMEOUT" and "PROCESS-CRASH".
* "toolkit/components/places/tests/browser/browser_bug248970.js" is the test file that reported the failure.
* "Check the total items count - Got 17, expected 16" is the error that occurred.

Below the failure line can be one or more bugs from Bugzilla that match up with part or all of the failure line, with the matching portions between the two highlighted in '''bold''' text. In this example, the entire bug summary (except for the added word "Intermittent") is in bold, meaning it matches up exactly with the failure line. (Careful, this only matches each individual word from the failure line to each word from the bug summary, so the order of words doesn't matter for highlighting purposes. You'll need to check yourself whether the two actually match for real.)

Next to the bug summary is a button with a 'pin' icon. If you click it, the job is added to the pinboard, and the bug number is added to the 'Bugs' section of the pinboard. Once you're confident that the classification is correct, you can click the pinboard's "Save" button to submit the classification to Treeherder's database. If this job isn't already classified, the job symbol will get a star icon added next to it.

That's it! You've classified/starred a job! You can move on to a different failed job.

= More Treeherder Resources =

More information about the Treeherder project can be found [[Auto-tools/Projects/Treeherder|here]].

Sheriffing/How To/Treeherder

2017-07-13T23:29:13Z

KWierso: Initial WIP page copied from Sheriffing/How:To:TBPL with a few modifications

MozWeek/SanFrancisco2018

2017-03-21T06:35:34Z

KWierso: /* Dates, Location and Weather */

'''What is it?''' -- Multiple team meetings, happening in the same city, at the same time + some opportunity to get together as one big group as well as with other teams as it makes sense. Then, on the last day, we have a fun social event for all, Mozilla-style!

'''''The information on this wiki primarily applies to Full time and contractor staff. If you are a volunteer contributor or intern, please inquire to your coordinator. '''''

=='''Dates, Location and Weather'''==
Monday, June 11 - Friday, June 16, 2018 (travel days are Monday the 11th & Saturday the 16th) in San Francisco, CA.

We are staying at [http://www.marriott.com/hotels/travel/sfodt-san-francisco-marriott-marquis/ San Francisco Marriott Marquis].

''*For those countries where rest time is required on weekends (vs. work travel), Mozilla will cover a return on the next available work day, if you choose. This needs to be pre-approved and pre-arranged.''

=='''Registration'''==
This is an invite-only event.

Sheriffing/How To/Unified Repos

2016-07-14T06:50:01Z

KWierso: /* hg aliases */

== Unified Repos ==
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

=== Setting up the repo ===
* Set up your ssh key yourself
* Install Mercurial 3.2 or higher
* Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* cd mozilla-central
* ./mach mercurial-setup
Configure mercurial as desired 
The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull fx-team && hg pull aurora && hg pull beta && hg pull esr38
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

Maybe rename the folder from "mozilla-central" to "unifiedrepo" or something to make it clear it's more than just mozilla-central?

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

With [https://bugzilla.mozilla.org/show_bug.cgi?id=1116861 bug 1116861] landed in version-control-tools, you can now use the following commands to pull from groups of repositories with a single command:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound, b2g-inbound, and fx-team branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

=== Merges ===
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, b2ginbound, fx-team, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

=== Checkin-neededs ===
This assumes we're checking things in to fx-team. Replace fx-team with another branch name as needed.

===== Single repository and single set of patches =====
Update fx-team and prepare for the patches:
* hg pull fx-team
* hg up fx-team
* hg bookmark fx-team-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all fx-team checkin-needed patches
Verify your outgoing changes:
* hg out -r . fx-team
If you haven't lost a push race:
* hg push -r . fx-team
If you lost a push race:
* hg pull fx-team
* hg rebase -d fx-team
* hg push -r . fx-team
Delete your no longer needed bookmark:
* hg bookmark -d fx-team-checkins

===== Multiple repositories with a single set of patches each =====
You can set up multiple sets of patches at once against multiple repositories:
Update fx-team
* hg pull fx-team && hg up fx-team
Create a bookmark to base your fx-team checkin-needed patches
* hg bookmark fxteam-checkins
Import a bunch of patches against fx-team
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your fx-team checkins and add another patch to the bookmark, then push it
* hg up fxteam-checkins
* hg import <patch5>
* hg out -r . fx-team # this will be patch1, patch2, and patch5
* hg push -r . fx-team
* hg bookmark -d fxteam-checkins

===== Single repository with multiple sets of patches =====
Or have multiple sets of patches against a single repository:
Update fx-team
* hg pull fx-team && hg up fx-team
Make the first bookmark/set
* hg bookmark fxteam-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up fx-team && hg bookmark fxteam-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . fx-team # patch3 and patch4
* hg up fxteam-checkins-1 && hg out -r . fx-team # patch1 and patch2
Push the first set
* hg push -r . fx-team # pushes patch1 and patch2
Get ready to push the second set
* hg up fxteam-checkins-2
* hg rebase -d fx-team # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . fx-team # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d fxteam-checkins-1
* hg bookmark -d fxteam-checkins-2

=== Uplifts ===
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

=== Backouts ===
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* hg backout -r <revision>
** 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).
* hg push -r . <tree>

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can still be used, though you will want to use `hg oops` in place of `hg qbackout` (eg if you use `hg share` to get multiple working directories, qbackout and other uses of mq do not play nice with shared repos):
* Copy the backout <revision> from treeherder
* hg oops -e -r <revision>
** This should open up your editor with a prepopulated commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg out -r . <tree>
** to double-check what you will be pushing
* hg push -r . <tree>

qbackout can also back out a range of commits in a single backout commit:
* hg oops -e -s -r <toprevision>:<bottomrevision>
** This will open your editor with a prepopulated commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg push -r . <tree>
(Omit oops's -s flag to back out each individual revision in the range as a separate commit.)

==== Revert a backout ====
* `hg graft`, see https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

=== Rebasing after losing a push race ===
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

=== Recovering from mistakes ===
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

You may also need to use some combination of the following to get things back to a known-good state:
* hg purge # http://mercurial.selenic.com/wiki/PurgeExtension
* hg up -C

=== See what you're about to push ===
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

=== View incoming changes ===
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

=== See the log for a particular branch ===
* hg log -fr [branch]

= Extras =
== hg aliases ==
=== mergetocentral/mergetointegration ===
I set up the following aliases in my global .hgrc file to make merging things around trunk a little faster:
[alias]
# merge tree $1, revision $2 to central, optionally appending $3 (for "CLOSED TREE", etc)
mergetocentral = !$HG pull central ; $HG up central ; $HG pull $1 ; $HG merge $2 ; $HG commit -m "Merge $1 to central, a=merge $3" ; $HG push -r . central
# merge central tip to tree $1, optionally appending $2 (for "CLOSED TREE", etc)
mergetointegration = !$HG pull central ; $HG pull $1 ; $HG up $1 ; $HG merge central ; $HG commit -m "Merge m-c to $1, a=merge $2" ; $HG push -r . $1

With these set up, I can merge fx-team's revision 04a3d9130aa0 over to mozilla-central with the following command:
hg mergetocentral fx-team 04a3d9130aa0
and then I can merge mozilla-central's tip back to fx-team with the following command:
hg mergetointegration fx-team
This cuts down on a lot of repetitive typing, saving a bit of time.

=== rbimport ===
For merging from reviewboard patches, there's this alias
rbimport = !hg transplant -e -s https://reviewboard-hg.mozilla.org/gecko -b $1

Then, it's matter of importing the right hash like the following command:
hg rbimport dd1462ba321db983061b94e30cee92b6bd81e908

Sheriffing/How To/Unified Repos

2016-07-14T06:49:20Z

KWierso: /* hg aliases */

== Unified Repos ==
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

=== Setting up the repo ===
* Set up your ssh key yourself
* Install Mercurial 3.2 or higher
* Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* cd mozilla-central
* ./mach mercurial-setup
Configure mercurial as desired 
The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull fx-team && hg pull aurora && hg pull beta && hg pull esr38
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

Maybe rename the folder from "mozilla-central" to "unifiedrepo" or something to make it clear it's more than just mozilla-central?

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

With [https://bugzilla.mozilla.org/show_bug.cgi?id=1116861 bug 1116861] landed in version-control-tools, you can now use the following commands to pull from groups of repositories with a single command:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound, b2g-inbound, and fx-team branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

=== Merges ===
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, b2ginbound, fx-team, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

=== Checkin-neededs ===
This assumes we're checking things in to fx-team. Replace fx-team with another branch name as needed.

===== Single repository and single set of patches =====
Update fx-team and prepare for the patches:
* hg pull fx-team
* hg up fx-team
* hg bookmark fx-team-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all fx-team checkin-needed patches
Verify your outgoing changes:
* hg out -r . fx-team
If you haven't lost a push race:
* hg push -r . fx-team
If you lost a push race:
* hg pull fx-team
* hg rebase -d fx-team
* hg push -r . fx-team
Delete your no longer needed bookmark:
* hg bookmark -d fx-team-checkins

===== Multiple repositories with a single set of patches each =====
You can set up multiple sets of patches at once against multiple repositories:
Update fx-team
* hg pull fx-team && hg up fx-team
Create a bookmark to base your fx-team checkin-needed patches
* hg bookmark fxteam-checkins
Import a bunch of patches against fx-team
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your fx-team checkins and add another patch to the bookmark, then push it
* hg up fxteam-checkins
* hg import <patch5>
* hg out -r . fx-team # this will be patch1, patch2, and patch5
* hg push -r . fx-team
* hg bookmark -d fxteam-checkins

===== Single repository with multiple sets of patches =====
Or have multiple sets of patches against a single repository:
Update fx-team
* hg pull fx-team && hg up fx-team
Make the first bookmark/set
* hg bookmark fxteam-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up fx-team && hg bookmark fxteam-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . fx-team # patch3 and patch4
* hg up fxteam-checkins-1 && hg out -r . fx-team # patch1 and patch2
Push the first set
* hg push -r . fx-team # pushes patch1 and patch2
Get ready to push the second set
* hg up fxteam-checkins-2
* hg rebase -d fx-team # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . fx-team # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d fxteam-checkins-1
* hg bookmark -d fxteam-checkins-2

=== Uplifts ===
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

=== Backouts ===
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* hg backout -r <revision>
** 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).
* hg push -r . <tree>

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can still be used, though you will want to use `hg oops` in place of `hg qbackout` (eg if you use `hg share` to get multiple working directories, qbackout and other uses of mq do not play nice with shared repos):
* Copy the backout <revision> from treeherder
* hg oops -e -r <revision>
** This should open up your editor with a prepopulated commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg out -r . <tree>
** to double-check what you will be pushing
* hg push -r . <tree>

qbackout can also back out a range of commits in a single backout commit:
* hg oops -e -s -r <toprevision>:<bottomrevision>
** This will open your editor with a prepopulated commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* hg push -r . <tree>
(Omit oops's -s flag to back out each individual revision in the range as a separate commit.)

==== Revert a backout ====
* `hg graft`, see https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

=== Rebasing after losing a push race ===
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

=== Recovering from mistakes ===
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

You may also need to use some combination of the following to get things back to a known-good state:
* hg purge # http://mercurial.selenic.com/wiki/PurgeExtension
* hg up -C

=== See what you're about to push ===
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

=== View incoming changes ===
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

=== See the log for a particular branch ===
* hg log -fr [branch]

= Extras =
== hg aliases ==
=== mergetocentral/mergetointegration ===
I set up the following aliases in my global .hgrc file to make merging things around trunk a little faster:
[alias]
# merge tree $1, revision $2 to central, optionally appending $3 (for "CLOSED TREE", etc)
mergetocentral = !$HG pull central ; $HG up central ; $HG pull $1 ; $HG merge $2 ; $HG commit -m "Merge $1 to central, a=merge $3" ; $HG push -r . central
# merge central tip to tree $1, optionally appending $2 (for "CLOSED TREE", etc)
mergetointegration = !$HG pull central ; $HG pull $1 ; $HG up $1 ; $HG merge central ; $HG commit -m "Merge m-c to $1, a=merge $2" ; $HG push -r . $1

With these set up, I can merge fx-team's revision 04a3d9130aa0 over to mozilla-central with the following command:
hg mergetocentral fx-team 04a3d9130aa0
and then I can merge mozilla-central's tip back to fx-team with the following command:
hg mergetointegration fx-team
This cuts down on a lot of repetitive typing, saving a bit of time.

For merging from reviewboard patches, there's this alias
rbimport = !hg transplant -e -s https://reviewboard-hg.mozilla.org/gecko -b $1

Then, it's matter of importing the right hash like the following command:
hg rbimport dd1462ba321db983061b94e30cee92b6bd81e908

Sheriffing/How To/Uplifts

2016-07-05T19:12:58Z

KWierso: Remove esr38 as it's reached end of life

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.

= Prerequisites =
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).

== Gecko Uplifts ==
=== Using Separate Repositories ===
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 (or revset).
# Transplant a cset from the specified branch to the current branch and edit the commit message.
# *** This assumes that local clones are named mozilla-XXX (aurora, beta, etc). ***
# Usage: hg uplift <source> <rev>
# Example: hg uplift aurora abc123abc123
uplift = transplant -e -s ../mozilla-$1 $2

Optionally, an mq-based alias can also be created, which exports a specified revision from the current clone and imports it into another.
# 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.
# *** This assumes that local clones are named mozilla-XXX (aurora, beta, etc). ***
# Usage: hg uplift-mq <branch> <bug#> <rev>
# Example: hg uplift-mq aurora 123456 abc123abc123
uplift-mq = !hg export -r $3 > ../mozilla-$1/.hg/patches/$2 && cd ../mozilla-$1 && hg qimport -e -P $2 && hg qref -e

NOTE: The above aliases work in opposite directions!

=== Using A Unified Repository ===
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.
hg graft -er <rev>

== Gaia Uplifts ==
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.
git cherry-pick <rev>
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.
git cherry-pick -m 1 <rev>
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.

= Uplift Procedure =
* Unless specifically cleared by Release Management, patches should land on mozilla-central prior to being uplifted elsewhere.
* 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.
* 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.
** Until bug 1154728 is resolved, note that Bugherder marks bugs in the *opposite* order of which they landed!
* If there is a branch-specific patch attached to the bug, use that. Otherwise, transplant it using the methods shown in the section above.
* Add a=<whoever approved> to the commit message.
* 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.

= Bug Queries =
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.

== B2G ==
Bug queries are on the [https://wiki.mozilla.org/Release_Management/B2G_Landing#Automatic_Branch_Uplifts B2G Landing] page.

== ESR ==
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).

ESR45

[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]

[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}]

=== For Crosschecks only ! Aurora ===
** NOTE ** These queries use date/milestone specific information that changes with every release!

[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;resolution=FIXED;field0-0-0=target_milestone;type0-0-0=anywordssubstr;value0-0-0={{NIGHTLY_VERSION}}%20{{AURORA_VERSION}};field0-1-0=flagtypes.name;type0-1-0=equals;value0-1-0=approval-mozilla-aurora%2B;field0-2-0=cf_status_firefox{{AURORA_VERSION}};type0-2-0=nowordssubstr;value0-2-0=fixed%20verified%20wontfix%20unaffected%20disabled; Fixed bugs with mozilla-aurora approval]

[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;resolution=FIXED;keywords=intermittent-failure;keywords_type=allwords;field0-0-0=target_milestone;type0-0-0=anywordssubstr;value0-0-0={{NIGHTLY_VERSION}}%20{{AURORA_VERSION}};field0-1-0=product;type0-1-0=nowordssubstr;value0-1-0=MailNews%20QA%20Thunderbird;field0-2-0=cf_status_firefox{{AURORA_VERSION}};type0-2-0=nowordssubstr;value0-2-0=fixed%20verified%20wontfix%20unaffected%20disabled; Fixed intermittents that affect Fx{{AURORA_VERSION}}]

=== For Crosschecks only ! Beta ===
** NOTE ** These queries use date/milestone specific information that changes with every release!

[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;resolution=FIXED;field0-0-0=target_milestone;type0-0-0=anywordssubstr;value0-0-0={{NIGHTLY_VERSION}}%20{{AURORA_VERSION}};field0-1-0=flagtypes.name;type0-1-0=equals;value0-1-0=approval-mozilla-beta%2B;field0-2-0=cf_status_firefox{{BETA_VERSION}};type0-2-0=nowordssubstr;value0-2-0=fixed%20verified%20wontfix%20unaffected%20disabled; Fixed bugs with mozilla-beta approval] (Test link with handy templates)

[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;resolution=FIXED;keywords=intermittent-failure;keywords_type=allwords;field0-0-0=target_milestone;type0-0-0=anywordssubstr;value0-0-0={{AURORA_VERSION}}%20{{NIGHTLY_VERSION}};field0-1-0=product;type0-1-0=nowordssubstr;value0-1-0=MailNews%20QA%20Thunderbird;field0-2-0=cf_status_firefox{{BETA_VERSION}};type0-2-0=nowordssubstr;value0-2-0=fixed%20verified%20wontfix%20unaffected%20disabled; Fixed intermittents that affect Fx{{BETA_VERSION}}]

EngineeringProductivity/Meetings/2016-04-18

2016-04-18T16:29:35Z

KWierso: VS2013

= Notices, Highlights, Roundtable =
* Significant Contributions
* Q2 deliverables and priorities
** Build system
** MozReview and Autoland
** TaskCluster
** Release process
* Open positions!
** https://careers.mozilla.org/position/ougZ2fwv
* London meetings
** Build system planning
** VCS workflows
** Automation data and metrics
** Developer productivity hacks
** MozReview design and planning
** MozReview hacking
** For others, please contact jgriffin by This Friday
* VS 2013 support?
** Bug 1186060 switched CI to using VS 2015. Bug 1232686 was backed out after we found out it broke VS 2013 builds. Email thread over the weekend suggested we officially unsupport VS 2013... can we make that official so that bug 1186060 can re-land?

= Newsgroup and Blog Posts =
* [armenzg] [http://armenzg.blogspot.ca/2016/04/improving-how-i-write-python-tests.html Improving how I write Python tests]
** pointers to other good blog posts and tips for people getting into Python tests
* [armenzg] [http://armenzg.blogspot.ca/2016/04/mozci-trigger-now-installs-with-pip.html mozci-trigger (command line script) nows installs with mozci-scripts (a new python package)]

= Goal Updates =

Please update Q2 deliverables: https://docs.google.com/spreadsheets/d/1WYhwdxMAgfU-YlfjTMXaf8EWTUMZi8KheMaaamK75Is/edit#gid=0

= Other Project Updates =

= Holidays and Trips =

* [ato] Away Friday 15 April and most of next week, except Thursday 21 April when I’m working from London

= Misc =

Sheriffing/How To/Uplifts

2016-03-14T19:08:49Z

KWierso: ESR45 queries

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.

= Prerequisites =
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).

== Gecko Uplifts ==
=== Using Separate Repositories ===
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 (or revset).
# Transplant a cset from the specified branch to the current branch and edit the commit message.
# *** This assumes that local clones are named mozilla-XXX (aurora, beta, etc). ***
# Usage: hg uplift <source> <rev>
# Example: hg uplift aurora abc123abc123
uplift = transplant -e -s ../mozilla-$1 $2

Optionally, an mq-based alias can also be created, which exports a specified revision from the current clone and imports it into another.
# 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.
# *** This assumes that local clones are named mozilla-XXX (aurora, beta, etc). ***
# Usage: hg uplift-mq <branch> <bug#> <rev>
# Example: hg uplift-mq aurora 123456 abc123abc123
uplift-mq = !hg export -r $3 > ../mozilla-$1/.hg/patches/$2 && cd ../mozilla-$1 && hg qimport -e -P $2 && hg qref -e

NOTE: The above aliases work in opposite directions!

=== Using A Unified Repository ===
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.
hg graft -er <rev>

== Gaia Uplifts ==
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.
git cherry-pick <rev>
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.
git cherry-pick -m 1 <rev>
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.

= Uplift Procedure =
* Unless specifically cleared by Release Management, patches should land on mozilla-central prior to being uplifted elsewhere.
* 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.
* 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.
** Until bug 1154728 is resolved, note that Bugherder marks bugs in the *opposite* order of which they landed!
* If there is a branch-specific patch attached to the bug, use that. Otherwise, transplant it using the methods shown in the section above.
* Add a=<whoever approved> to the commit message.
* 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.

= Bug Queries =
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.

== B2G ==
Bug queries are on the [https://wiki.mozilla.org/Release_Management/B2G_Landing#Automatic_Branch_Uplifts B2G Landing] page.

== ESR ==
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).

ESR45

[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]

[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}]

ESR38

[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;field0-0-0=flagtypes.name;type0-0-0=equals;value0-0-0=approval-mozilla-esr38%2B;field0-1-0=cf_status_firefox_esr38;type0-1-0=nowordssubstr;value0-1-0=fixed%20verified%20wontfix%20unaffected%20disabled All esr38 approvals not yet uplifted]

[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_esr38&type0-3-0=nowordssubstr&value0-3-0=fixed%20verified%20wontfix%20unaffected%20disabled Fixed intermittents w/o esr38 {fixed|verified|wontfix|unaffected|disabled}]

=== For Crosschecks only ! Aurora ===
** NOTE ** These queries use date/milestone specific information that changes with every release!

[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;resolution=FIXED;field0-0-0=target_milestone;type0-0-0=anywordssubstr;value0-0-0={{NIGHTLY_VERSION}}%20{{AURORA_VERSION}};field0-1-0=flagtypes.name;type0-1-0=equals;value0-1-0=approval-mozilla-aurora%2B;field0-2-0=cf_status_firefox{{AURORA_VERSION}};type0-2-0=nowordssubstr;value0-2-0=fixed%20verified%20wontfix%20unaffected%20disabled; Fixed bugs with mozilla-aurora approval]

[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;resolution=FIXED;keywords=intermittent-failure;keywords_type=allwords;field0-0-0=target_milestone;type0-0-0=anywordssubstr;value0-0-0={{NIGHTLY_VERSION}}%20{{AURORA_VERSION}};field0-1-0=product;type0-1-0=nowordssubstr;value0-1-0=MailNews%20QA%20Thunderbird;field0-2-0=cf_status_firefox{{AURORA_VERSION}};type0-2-0=nowordssubstr;value0-2-0=fixed%20verified%20wontfix%20unaffected%20disabled; Fixed intermittents that affect Fx{{AURORA_VERSION}}]

=== For Crosschecks only ! Beta ===
** NOTE ** These queries use date/milestone specific information that changes with every release!

[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;resolution=FIXED;field0-0-0=target_milestone;type0-0-0=anywordssubstr;value0-0-0={{NIGHTLY_VERSION}}%20{{AURORA_VERSION}};field0-1-0=flagtypes.name;type0-1-0=equals;value0-1-0=approval-mozilla-beta%2B;field0-2-0=cf_status_firefox{{BETA_VERSION}};type0-2-0=nowordssubstr;value0-2-0=fixed%20verified%20wontfix%20unaffected%20disabled; Fixed bugs with mozilla-beta approval] (Test link with handy templates)

[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;resolution=FIXED;keywords=intermittent-failure;keywords_type=allwords;field0-0-0=target_milestone;type0-0-0=anywordssubstr;value0-0-0={{AURORA_VERSION}}%20{{NIGHTLY_VERSION}};field0-1-0=product;type0-1-0=nowordssubstr;value0-1-0=MailNews%20QA%20Thunderbird;field0-2-0=cf_status_firefox{{BETA_VERSION}};type0-2-0=nowordssubstr;value0-2-0=fixed%20verified%20wontfix%20unaffected%20disabled; Fixed intermittents that affect Fx{{BETA_VERSION}}]

Sheriffing/How To/Uplifts

2015-12-22T23:54:36Z

KWierso: Fix beta intermittent fix text

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.

= Prerequisites =
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).

== Gecko Uplifts ==
=== Using Separate Repositories ===
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 (or revset).
# Transplant a cset from the specified branch to the current branch and edit the commit message.
# *** This assumes that local clones are named mozilla-XXX (aurora, beta, etc). ***
# Usage: hg uplift <source> <rev>
# Example: hg uplift aurora abc123abc123
uplift = transplant -e -s ../mozilla-$1 $2

Optionally, an mq-based alias can also be created, which exports a specified revision from the current clone and imports it into another.
# 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.
# *** This assumes that local clones are named mozilla-XXX (aurora, beta, etc). ***
# Usage: hg uplift-mq <branch> <bug#> <rev>
# Example: hg uplift-mq aurora 123456 abc123abc123
uplift-mq = !hg export -r $3 > ../mozilla-$1/.hg/patches/$2 && cd ../mozilla-$1 && hg qimport -e -P $2 && hg qref -e

NOTE: The above aliases work in opposite directions!

=== Using A Unified Repository ===
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.
hg graft -er <rev>

== Gaia Uplifts ==
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.
git cherry-pick <rev>
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.
git cherry-pick -m 1 <rev>
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.

= Uplift Procedure =
* Unless specifically cleared by Release Management, patches should land on mozilla-central prior to being uplifted elsewhere.
* 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.
* 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.
** Until bug 1154728 is resolved, note that Bugherder marks bugs in the *opposite* order of which they landed!
* If there is a branch-specific patch attached to the bug, use that. Otherwise, transplant it using the methods shown in the section above.
* Add a=<whoever approved> to the commit message.
* 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.

= Bug Queries =
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.

== B2G ==
Bug queries are on the [https://wiki.mozilla.org/Release_Management/B2G_Landing#Automatic_Branch_Uplifts B2G Landing] page.

== ESR ==
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).

ESR38

[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;field0-0-0=flagtypes.name;type0-0-0=equals;value0-0-0=approval-mozilla-esr38%2B;field0-1-0=cf_status_firefox_esr38;type0-1-0=nowordssubstr;value0-1-0=fixed%20verified%20wontfix%20unaffected%20disabled All esr38 approvals not yet uplifted]

[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_esr38&type0-3-0=nowordssubstr&value0-3-0=fixed%20verified%20wontfix%20unaffected%20disabled Fixed intermittents w/o esr38 {fixed|verified|wontfix|unaffected|disabled}]

== Aurora ==
** NOTE ** These queries use date/milestone specific information that changes with every release!

[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;resolution=FIXED;field0-0-0=target_milestone;type0-0-0=anywordssubstr;value0-0-0={{NIGHTLY_VERSION}}%20{{AURORA_VERSION}};field0-1-0=flagtypes.name;type0-1-0=equals;value0-1-0=approval-mozilla-aurora%2B;field0-2-0=cf_status_firefox{{AURORA_VERSION}};type0-2-0=nowordssubstr;value0-2-0=fixed%20verified%20wontfix%20unaffected%20disabled; Fixed bugs with mozilla-aurora approval]

[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;resolution=FIXED;keywords=intermittent-failure;keywords_type=allwords;field0-0-0=target_milestone;type0-0-0=anywordssubstr;value0-0-0={{NIGHTLY_VERSION}}%20{{AURORA_VERSION}};field0-1-0=product;type0-1-0=nowordssubstr;value0-1-0=MailNews%20QA%20Thunderbird;field0-2-0=cf_status_firefox{{AURORA_VERSION}};type0-2-0=nowordssubstr;value0-2-0=fixed%20verified%20wontfix%20unaffected%20disabled; Fixed intermittents that affect Fx{{AURORA_VERSION}}]

== Beta ==
** NOTE ** These queries use date/milestone specific information that changes with every release!

[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;resolution=FIXED;field0-0-0=target_milestone;type0-0-0=anywordssubstr;value0-0-0={{NIGHTLY_VERSION}}%20{{AURORA_VERSION}};field0-1-0=flagtypes.name;type0-1-0=equals;value0-1-0=approval-mozilla-beta%2B;field0-2-0=cf_status_firefox{{BETA_VERSION}};type0-2-0=nowordssubstr;value0-2-0=fixed%20verified%20wontfix%20unaffected%20disabled; Fixed bugs with mozilla-beta approval] (Test link with handy templates)

[https://bugzilla.mozilla.org/buglist.cgi?order=cf_last_resolved;resolution=FIXED;keywords=intermittent-failure;keywords_type=allwords;field0-0-0=target_milestone;type0-0-0=anywordssubstr;value0-0-0={{AURORA_VERSION}}%20{{NIGHTLY_VERSION}};field0-1-0=product;type0-1-0=nowordssubstr;value0-1-0=MailNews%20QA%20Thunderbird;field0-2-0=cf_status_firefox{{BETA_VERSION}};type0-2-0=nowordssubstr;value0-2-0=fixed%20verified%20wontfix%20unaffected%20disabled; Fixed intermittents that affect Fx44]

Sheriffing/How To/Unified Repos

2015-10-16T17:16:10Z

KWierso: hg log -fr [branch]

== Unified Repos ==
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

=== Setting up the repo ===
* Set up your ssh key yourself
* Install Mercurial 3.2 or higher
* Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* cd mozilla-central
* ./mach mercurial-setup
Configure mercurial as desired 
The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull b2ginbound && hg pull fx-team && hg pull aurora && hg pull beta && hg pull esr31 && hg pull b2g34 && hg pull b2g32 && hg pull b2g30
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

Maybe rename the folder from "mozilla-central" to "unifiedrepo" or something to make it clear it's more than just mozilla-central?

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

With [https://bugzilla.mozilla.org/show_bug.cgi?id=1116861 bug 1116861] landed in version-control-tools, you can now use the following commands to pull from groups of repositories with a single command:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound, b2g-inbound, and fx-team branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

=== Merges ===
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, b2ginbound, fx-team, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

=== Checkin-neededs ===
This assumes we're checking things in to fx-team. Replace fx-team with another branch name as needed.

===== Single repository and single set of patches =====
Update fx-team and prepare for the patches:
* hg pull fx-team
* hg up fx-team
* hg bookmark fx-team-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all fx-team checkin-needed patches
Verify your outgoing changes:
* hg out -r . fx-team
If you haven't lost a push race:
* hg push -r . fx-team
If you lost a push race:
* hg pull fx-team
* hg rebase -d fx-team
* hg push -r . fx-team
Delete your no longer needed bookmark:
* hg bookmark -d fx-team-checkins

===== Multiple repositories with a single set of patches each =====
You can set up multiple sets of patches at once against multiple repositories:
Update fx-team
* hg pull fx-team && hg up fx-team
Create a bookmark to base your fx-team checkin-needed patches
* hg bookmark fxteam-checkins
Import a bunch of patches against fx-team
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your fx-team checkins and add another patch to the bookmark, then push it
* hg up fxteam-checkins
* hg import <patch5>
* hg out -r . fx-team # this will be patch1, patch2, and patch5
* hg push -r . fx-team
* hg bookmark -d fxteam-checkins

===== Single repository with multiple sets of patches =====
Or have multiple sets of patches against a single repository:
Update fx-team
* hg pull fx-team && hg up fx-team
Make the first bookmark/set
* hg bookmark fxteam-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up fx-team && hg bookmark fxteam-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . fx-team # patch3 and patch4
* hg up fxteam-checkins-1 && hg out -r . fx-team # patch1 and patch2
Push the first set
* hg push -r . fx-team # pushes patch1 and patch2
Get ready to push the second set
* hg up fxteam-checkins-2
* hg rebase -d fx-team # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . fx-team # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d fxteam-checkins-1
* hg bookmark -d fxteam-checkins-2

=== Uplifts ===
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

=== Backouts ===
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* `hg backout -r <revision>`
** 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).
* `hg push -r . <tree>`

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can probably still be used (assuming you don't use `hg share` to get multiple working directories, as mq doesn't play nice with shared repos):
* Copy the backout <revision> from treeherder
* `hg qbackout -e -r <revision>`
** This should open up your editor with a pre-formed commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a && hg push -r . <tree>`

qbackout can also back out a range of commits in a single backout commit:
* `hg qbackout -e -s -r <toprevision>:<bottomrevision>`
** This will open your editor with a pre-formed commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a ** hg push -r . <tree>`
(Omit qbackout's -s flag to back out each individual revision in the range as a separate commit.)

==== Revert a backout ====
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

=== Rebasing after losing a push race ===
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

=== Recovering from mistakes ===
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

You may also need to use some combination of the following to get things back to a known-good state:
* hg purge # http://mercurial.selenic.com/wiki/PurgeExtension
* hg up -C

=== See what you're about to push ===
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

=== View incoming changes ===
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

=== See the log for a particular log ===
* hg log -fr [branch]

= Extras =
== hg aliases ==
I set up the following aliases in my global .hgrc file to make merging things around trunk a little faster:
[alias]
# merge tree $1, revision $2 to central, optionally appending $3 (for "CLOSED TREE", etc)
mergetocentral = !$HG pull central ; $HG up central ; $HG pull $1 ; $HG merge $2 ; $HG commit -m "Merge $1 to central, a=merge $3" ; $HG push -r . central
# merge central tip to tree $1, optionally appending $2 (for "CLOSED TREE", etc)
mergetointegration = !$HG pull central ; $HG pull $1 ; $HG up $1 ; $HG merge central ; $HG commit -m "Merge m-c to $1, a=merge $2" ; $HG push -r . $1

With these set up, I can merge fx-team's revision 04a3d9130aa0 over to mozilla-central with the following command:
hg mergetocentral fx-team 04a3d9130aa0
and then I can merge mozilla-central's tip back to fx-team with the following command:
hg mergetointegration fx-team
This cuts down on a lot of repetitive typing, saving a bit of time.

For merging from reviewboard patches, there's this alias
rbimport = !hg transplant -e -s https://reviewboard-hg.mozilla.org/gecko -b $1

Then, it's matter of importing the right hash like the following command:
hg rbimport dd1462ba321db983061b94e30cee92b6bd81e908

Sheriffing/How To/Unified Repos

2015-06-03T01:53:28Z

KWierso: /* Extras */

== Unified Repos ==
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

=== Setting up the repo ===
* Set up your ssh key yourself
* Install Mercurial 3.2 or higher
* Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* cd mozilla-central
* ./mach mercurial-setup
Configure mercurial as desired 
The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull b2ginbound && hg pull fx-team && hg pull aurora && hg pull beta && hg pull esr31 && hg pull b2g34 && hg pull b2g32 && hg pull b2g30
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

Maybe rename the folder from "mozilla-central" to "unifiedrepo" or something to make it clear it's more than just mozilla-central?

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

With [https://bugzilla.mozilla.org/show_bug.cgi?id=1116861 bug 1116861] landed in version-control-tools, you can now use the following commands to pull from groups of repositories with a single command:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound, b2g-inbound, and fx-team branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

=== Merges ===
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, b2ginbound, fx-team, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

=== Checkin-neededs ===
This assumes we're checking things in to fx-team. Replace fx-team with another branch name as needed.

===== Single repository and single set of patches =====
Update fx-team and prepare for the patches:
* hg pull fx-team
* hg up fx-team
* hg bookmark fx-team-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all fx-team checkin-needed patches
Verify your outgoing changes:
* hg out -r . fx-team
If you haven't lost a push race:
* hg push -r . fx-team
If you lost a push race:
* hg pull fx-team
* hg rebase -d fx-team
* hg push -r . fx-team
Delete your no longer needed bookmark:
* hg bookmark -d fx-team-checkins

===== Multiple repositories with a single set of patches each =====
You can set up multiple sets of patches at once against multiple repositories:
Update fx-team
* hg pull fx-team && hg up fx-team
Create a bookmark to base your fx-team checkin-needed patches
* hg bookmark fxteam-checkins
Import a bunch of patches against fx-team
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your fx-team checkins and add another patch to the bookmark, then push it
* hg up fxteam-checkins
* hg import <patch5>
* hg out -r . fx-team # this will be patch1, patch2, and patch5
* hg push -r . fx-team
* hg bookmark -d fxteam-checkins

===== Single repository with multiple sets of patches =====
Or have multiple sets of patches against a single repository:
Update fx-team
* hg pull fx-team && hg up fx-team
Make the first bookmark/set
* hg bookmark fxteam-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up fx-team && hg bookmark fxteam-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . fx-team # patch3 and patch4
* hg up fxteam-checkins-1 && hg out -r . fx-team # patch1 and patch2
Push the first set
* hg push -r . fx-team # pushes patch1 and patch2
Get ready to push the second set
* hg up fxteam-checkins-2
* hg rebase -d fx-team # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . fx-team # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d fxteam-checkins-1
* hg bookmark -d fxteam-checkins-2

=== Uplifts ===
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

=== Backouts ===
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* `hg backout -r <revision>`
** 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).
* `hg push -r . <tree>`

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can probably still be used (assuming you don't use `hg share` to get multiple working directories, as mq doesn't play nice with shared repos):
* Copy the backout <revision> from treeherder
* `hg qbackout -e -r <revision>`
** This should open up your editor with a pre-formed commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a && hg push -r . <tree>`

qbackout can also back out a range of commits in a single backout commit:
* `hg qbackout -e -s -r <toprevision>:<bottomrevision>`
** This will open your editor with a pre-formed commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a ** hg push -r . <tree>`
(Omit qbackout's -s flag to back out each individual revision in the range as a separate commit.)

==== Revert a backout ====
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

=== Rebasing after losing a push race ===
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

=== Recovering from mistakes ===
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

You may also need to use some combination of the following to get things back to a known-good state:
* hg purge # http://mercurial.selenic.com/wiki/PurgeExtension
* hg up -C

=== See what you're about to push ===
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

=== View incoming changes ===
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

= Extras =
== hg aliases ==
I set up the following aliases in my global .hgrc file to make merging things around trunk a little faster:
[alias]
# merge tree $1, revision $2 to central, optionally appending $3 (for "CLOSED TREE", etc)
mergetocentral = !$HG pull central ; $HG up central ; $HG pull $1 ; $HG merge $2 ; $HG commit -m "Merge $1 to central, a=merge $3" ; $HG push -r . central
# merge central tip to tree $1, optionally appending $2 (for "CLOSED TREE", etc)
mergetointegration = !$HG pull central ; $HG pull $1 ; $HG up $1 ; $HG merge central ; $HG commit -m "Merge m-c to $1, a=merge $2" ; $HG push -r . $1

With these set up, I can merge fx-team's revision 04a3d9130aa0 over to mozilla-central with the following command:
hg mergetocentral fx-team 04a3d9130aa0
and then I can merge mozilla-central's tip back to fx-team with the following command:
hg mergetointegration fx-team
This cuts down on a lot of repetitive typing, saving a bit of time.

Sheriffing/How To/Unified Repos

2015-06-03T01:52:45Z

KWierso: Added some useful hg aliases.

== Unified Repos ==
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

=== Setting up the repo ===
* Set up your ssh key yourself
* Install Mercurial 3.2 or higher
* Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* cd mozilla-central
* ./mach mercurial-setup
Configure mercurial as desired 
The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull b2ginbound && hg pull fx-team && hg pull aurora && hg pull beta && hg pull esr31 && hg pull b2g34 && hg pull b2g32 && hg pull b2g30
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

Maybe rename the folder from "mozilla-central" to "unifiedrepo" or something to make it clear it's more than just mozilla-central?

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

With [https://bugzilla.mozilla.org/show_bug.cgi?id=1116861 bug 1116861] landed in version-control-tools, you can now use the following commands to pull from groups of repositories with a single command:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound, b2g-inbound, and fx-team branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

=== Merges ===
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, b2ginbound, fx-team, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

=== Checkin-neededs ===
This assumes we're checking things in to fx-team. Replace fx-team with another branch name as needed.

===== Single repository and single set of patches =====
Update fx-team and prepare for the patches:
* hg pull fx-team
* hg up fx-team
* hg bookmark fx-team-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all fx-team checkin-needed patches
Verify your outgoing changes:
* hg out -r . fx-team
If you haven't lost a push race:
* hg push -r . fx-team
If you lost a push race:
* hg pull fx-team
* hg rebase -d fx-team
* hg push -r . fx-team
Delete your no longer needed bookmark:
* hg bookmark -d fx-team-checkins

===== Multiple repositories with a single set of patches each =====
You can set up multiple sets of patches at once against multiple repositories:
Update fx-team
* hg pull fx-team && hg up fx-team
Create a bookmark to base your fx-team checkin-needed patches
* hg bookmark fxteam-checkins
Import a bunch of patches against fx-team
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your fx-team checkins and add another patch to the bookmark, then push it
* hg up fxteam-checkins
* hg import <patch5>
* hg out -r . fx-team # this will be patch1, patch2, and patch5
* hg push -r . fx-team
* hg bookmark -d fxteam-checkins

===== Single repository with multiple sets of patches =====
Or have multiple sets of patches against a single repository:
Update fx-team
* hg pull fx-team && hg up fx-team
Make the first bookmark/set
* hg bookmark fxteam-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up fx-team && hg bookmark fxteam-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . fx-team # patch3 and patch4
* hg up fxteam-checkins-1 && hg out -r . fx-team # patch1 and patch2
Push the first set
* hg push -r . fx-team # pushes patch1 and patch2
Get ready to push the second set
* hg up fxteam-checkins-2
* hg rebase -d fx-team # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . fx-team # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d fxteam-checkins-1
* hg bookmark -d fxteam-checkins-2

=== Uplifts ===
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

=== Backouts ===
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* `hg backout -r <revision>`
** 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).
* `hg push -r . <tree>`

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can probably still be used (assuming you don't use `hg share` to get multiple working directories, as mq doesn't play nice with shared repos):
* Copy the backout <revision> from treeherder
* `hg qbackout -e -r <revision>`
** This should open up your editor with a pre-formed commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a && hg push -r . <tree>`

qbackout can also back out a range of commits in a single backout commit:
* `hg qbackout -e -s -r <toprevision>:<bottomrevision>`
** This will open your editor with a pre-formed commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a ** hg push -r . <tree>`
(Omit qbackout's -s flag to back out each individual revision in the range as a separate commit.)

==== Revert a backout ====
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

=== Rebasing after losing a push race ===
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

=== Recovering from mistakes ===
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

You may also need to use some combination of the following to get things back to a known-good state:
* hg purge # http://mercurial.selenic.com/wiki/PurgeExtension
* hg up -C

=== See what you're about to push ===
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

=== View incoming changes ===
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

= Extras =
I set up the following aliases in my global .hgrc file to make merging things around trunk a little faster:
[alias]
# merge tree $1, revision $2 to central, optionally appending $3 (for "CLOSED TREE", etc)
mergetocentral = !$HG pull central ; $HG up central ; $HG pull $1 ; $HG merge $2 ; $HG commit -m "Merge $1 to central, a=merge $3" ; $HG push -r . central
# merge central tip to tree $1, optionally appending $2 (for "CLOSED TREE", etc)
mergetointegration = !$HG pull central ; $HG pull $1 ; $HG up $1 ; $HG merge central ; $HG commit -m "Merge m-c to $1, a=merge $2" ; $HG push -r . $1

With these set up, I can merge fx-team's revision 04a3d9130aa0 over to mozilla-central with the following command:
hg mergetocentral fx-team 04a3d9130aa0
and then I can merge mozilla-central's tip back to fx-team with the following command:
hg mergetointegration fx-team
This cuts down on a lot of repetitive typing, saving a bit of time.

Auto-tools/Meetings/2015-05-04

2015-05-04T16:50:56Z

KWierso: /* Misc */

= Notices, Highlights, Roundtable =
* Significant Contributions
* Releng work week recap
* MozReview now has autoland-to-try
* ActiveData testfile explorer discussion

= Newsgroup and Blog Posts =
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/4aTa1iEUuXY You can now log into BMO with your GitHub account]
* [https://gbrownmozilla.wordpress.com/2015/04/23/android-4-3-opt-tests-running-on-trunk-trees/ Android 4.3 opt tests]

= Goal Updates =

* Please update status at https://docs.google.com/a/mozilla.com/document/d/1U3VXk7K5iTmZvqqtX4sc-Znhch9ZAD98Vl1OyWRqZwo/edit#

= Other Project Updates =

= Holidays and Trips =

= Misc =

Auto-tools/Meetings/2015-05-04

2015-04-27T18:22:55Z

KWierso: Bugherder

= Notices, Highlights, Roundtable =
* Significant Contributions

= Newsgroup and Blog Posts =
* [https://groups.google.com/forum/#!topic/mozilla.dev.platform/4aTa1iEUuXY You can now log into BMO with your GitHub account]

= Goal Updates =

= Other Project Updates =

= Holidays and Trips =

= Misc =
== Adding tests to Bugherder ==
I'm wanting to add a test framework (and then tests) to Bugherder (formerly mcMerge) in bug 1156095, but I don't know where to start. It's all HTML/JS, no Node or anything fancy. Would like it to be run per-push to the Github repo (and on pull requests) as well as able to run locally. Any suggestions?

Sheriffing/How To/Unified Repos

2015-03-19T20:22:29Z

KWierso: /* Setting up the repo */

== Unified Repos ==
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

=== Setting up the repo ===
* Set up your ssh key yourself
* Install Mercurial 3.2 or higher
* Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* cd mozilla-central
* ./mach mercurial-setup
Configure mercurial as desired 
The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull b2ginbound && hg pull fx-team && hg pull aurora && hg pull beta && hg pull esr31 && hg pull b2g34 && hg pull b2g32 && hg pull b2g30
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

Maybe rename the folder from "mozilla-central" to "unifiedrepo" or something to make it clear it's more than just mozilla-central?

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

With [https://bugzilla.mozilla.org/show_bug.cgi?id=1116861 bug 1116861] landed in version-control-tools, you can now use the following commands to pull from groups of repositories with a single command:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound, b2g-inbound, and fx-team branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

=== Merges ===
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, b2ginbound, fx-team, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

=== Checkin-neededs ===
This assumes we're checking things in to fx-team. Replace fx-team with another branch name as needed.

===== Single repository and single set of patches =====
Update fx-team and prepare for the patches:
* hg pull fx-team
* hg up fx-team
* hg bookmark fx-team-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all fx-team checkin-needed patches
Verify your outgoing changes:
* hg out -r . fx-team
If you haven't lost a push race:
* hg push -r . fx-team
If you lost a push race:
* hg pull fx-team
* hg rebase -d fx-team
* hg push -r . fx-team
Delete your no longer needed bookmark:
* hg bookmark -d fx-team-checkins

===== Multiple repositories with a single set of patches each =====
You can set up multiple sets of patches at once against multiple repositories:
Update fx-team
* hg pull fx-team && hg up fx-team
Create a bookmark to base your fx-team checkin-needed patches
* hg bookmark fxteam-checkins
Import a bunch of patches against fx-team
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your fx-team checkins and add another patch to the bookmark, then push it
* hg up fxteam-checkins
* hg import <patch5>
* hg out -r . fx-team # this will be patch1, patch2, and patch5
* hg push -r . fx-team
* hg bookmark -d fxteam-checkins

===== Single repository with multiple sets of patches =====
Or have multiple sets of patches against a single repository:
Update fx-team
* hg pull fx-team && hg up fx-team
Make the first bookmark/set
* hg bookmark fxteam-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up fx-team && hg bookmark fxteam-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . fx-team # patch3 and patch4
* hg up fxteam-checkins-1 && hg out -r . fx-team # patch1 and patch2
Push the first set
* hg push -r . fx-team # pushes patch1 and patch2
Get ready to push the second set
* hg up fxteam-checkins-2
* hg rebase -d fx-team # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . fx-team # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d fxteam-checkins-1
* hg bookmark -d fxteam-checkins-2

=== Uplifts ===
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

=== Backouts ===
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* `hg backout -r <revision>`
** 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).
* `hg push -r . <tree>`

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can probably still be used (assuming you don't use `hg share` to get multiple working directories, as mq doesn't play nice with shared repos):
* Copy the backout <revision> from treeherder
* `hg qbackout -e -r <revision>`
** This should open up your editor with a pre-formed commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a && hg push -r . <tree>`

qbackout can also back out a range of commits in a single backout commit:
* `hg qbackout -e -s -r <toprevision>:<bottomrevision>`
** This will open your editor with a pre-formed commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a ** hg push -r . <tree>`
(Omit qbackout's -s flag to back out each individual revision in the range as a separate commit.)

==== Revert a backout ====
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

=== Rebasing after losing a push race ===
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

=== Recovering from mistakes ===
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

You may also need to use some combination of the following to get things back to a known-good state:
* hg purge # http://mercurial.selenic.com/wiki/PurgeExtension
* hg up -C

=== See what you're about to push ===
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

=== View incoming changes ===
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

Sheriffing/How To/Unified Repos

2015-03-05T19:56:38Z

KWierso: /* Recovering from mistakes */

== Unified Repos ==
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

=== Setting up the repo ===
* Set up your ssh key yourself
* Install Mercurial 3.2 or higher
* Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* hg clone https://hg.mozilla.org/hgcustom/version-control-tools
* cd mozilla-central
* ./mach mercurial-setup
Configure mercurial as desired (do not enable the mq extension) 
Edit your global .hgrc file to add the following to the [extensions] section:
*firefoxtree = /path/to/version-control-tools/hgext/firefoxtree
The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull b2ginbound && hg pull fx-team && hg pull aurora && hg pull beta && hg pull esr31 && hg pull b2g34 && hg pull b2g32 && hg pull b2g30
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

Maybe rename the folder from "mozilla-central" to "unifiedrepo" or something to make it clear it's more than just mozilla-central?

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

With [https://bugzilla.mozilla.org/show_bug.cgi?id=1116861 bug 1116861] landed in version-control-tools, you can now use the following commands to pull from groups of repositories with a single command:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound, b2g-inbound, and fx-team branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

=== Merges ===
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, b2ginbound, fx-team, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

=== Checkin-neededs ===
This assumes we're checking things in to fx-team. Replace fx-team with another branch name as needed.

===== Single repository and single set of patches =====
Update fx-team and prepare for the patches:
* hg pull fx-team
* hg up fx-team
* hg bookmark fx-team-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all fx-team checkin-needed patches
Verify your outgoing changes:
* hg out -r . fx-team
If you haven't lost a push race:
* hg push -r . fx-team
If you lost a push race:
* hg pull fx-team
* hg rebase -d fx-team
* hg push -r . fx-team
Delete your no longer needed bookmark:
* hg bookmark -d fx-team-checkins

===== Multiple repositories with a single set of patches each =====
You can set up multiple sets of patches at once against multiple repositories:
Update fx-team
* hg pull fx-team && hg up fx-team
Create a bookmark to base your fx-team checkin-needed patches
* hg bookmark fxteam-checkins
Import a bunch of patches against fx-team
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your fx-team checkins and add another patch to the bookmark, then push it
* hg up fxteam-checkins
* hg import <patch5>
* hg out -r . fx-team # this will be patch1, patch2, and patch5
* hg push -r . fx-team
* hg bookmark -d fxteam-checkins

===== Single repository with multiple sets of patches =====
Or have multiple sets of patches against a single repository:
Update fx-team
* hg pull fx-team && hg up fx-team
Make the first bookmark/set
* hg bookmark fxteam-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up fx-team && hg bookmark fxteam-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . fx-team # patch3 and patch4
* hg up fxteam-checkins-1 && hg out -r . fx-team # patch1 and patch2
Push the first set
* hg push -r . fx-team # pushes patch1 and patch2
Get ready to push the second set
* hg up fxteam-checkins-2
* hg rebase -d fx-team # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . fx-team # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d fxteam-checkins-1
* hg bookmark -d fxteam-checkins-2

=== Uplifts ===
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

=== Backouts ===
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* `hg backout -r <revision>`
** 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).
* `hg push -r . <tree>`

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can probably still be used (assuming you don't use `hg share` to get multiple working directories, as mq doesn't play nice with shared repos):
* Copy the backout <revision> from treeherder
* `hg qbackout -e -r <revision>`
** This should open up your editor with a pre-formed commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a && hg push -r . <tree>`

qbackout can also back out a range of commits in a single backout commit:
* `hg qbackout -e -s -r <toprevision>:<bottomrevision>`
** This will open your editor with a pre-formed commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a ** hg push -r . <tree>`
(Omit qbackout's -s flag to back out each individual revision in the range as a separate commit.)

==== Revert a backout ====
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

=== Rebasing after losing a push race ===
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

=== Recovering from mistakes ===
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

You may also need to use some combination of the following to get things back to a known-good state:
* hg purge # http://mercurial.selenic.com/wiki/PurgeExtension
* hg up -C

=== See what you're about to push ===
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

=== View incoming changes ===
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

Auto-tools/The Sheriffs

2015-02-09T16:13:33Z

KWierso: KWierso

{| class="wikitable"
|-
! Name
! IRC
! Duty Times
! Info
! core areas of involvement and more about me
|-
| Carsten Book
| Tomcat
| Sheriffduty from 8am to 5pm German Time
| [https://phonebook.mozilla.org/tree.php#search/cbook@mozilla.com ldap], [https://mozillians.org/en-US/u/Tomcat/ Mozillians]
| sheriffing, bughunter, troubleshooter. Living in Freising - Bavaria Germany and you can Read more about my contributor story [http://blog.mozilla.org/tomcat/2013/10/21/getting-started-in-the-community-today/ here] - I love working with Computers, Icehockey and Soccer
|-
| Wes Kocher
| KWierso
| Pacific Timezone (typically on duty in afternoons)
|
|
|}

Sheriffing/How To/Unified Repos

2015-02-07T02:08:41Z

KWierso: Formatting fix

== Unified Repos ==
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

=== Setting up the repo ===
* Set up your ssh key yourself
* Install Mercurial 3.2 or higher
* Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* hg clone https://hg.mozilla.org/hgcustom/version-control-tools
* cd mozilla-central
* ./mach mercurial-setup
Configure mercurial as desired (do not enable the mq extension) 
Edit your global .hgrc file to add the following to the [extensions] section:
*firefoxtree = /path/to/version-control-tools/hgext/firefoxtree
The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull b2ginbound && hg pull fx-team && hg pull aurora && hg pull beta && hg pull esr31 && hg pull b2g34 && hg pull b2g32 && hg pull b2g30
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

Maybe rename the folder from "mozilla-central" to "unifiedrepo" or something to make it clear it's more than just mozilla-central?

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

With [https://bugzilla.mozilla.org/show_bug.cgi?id=1116861 bug 1116861] landed in version-control-tools, you can now use the following commands to pull from groups of repositories with a single command:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound, b2g-inbound, and fx-team branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

=== Merges ===
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, b2ginbound, fx-team, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

=== Checkin-neededs ===
This assumes we're checking things in to fx-team. Replace fx-team with another branch name as needed.

===== Single repository and single set of patches =====
Update fx-team and prepare for the patches:
* hg pull fx-team
* hg up fx-team
* hg bookmark fx-team-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all fx-team checkin-needed patches
Verify your outgoing changes:
* hg out -r . fx-team
If you haven't lost a push race:
* hg push -r . fx-team
If you lost a push race:
* hg pull fx-team
* hg rebase -d fx-team
* hg push -r . fx-team
Delete your no longer needed bookmark:
* hg bookmark -d fx-team-checkins

===== Multiple repositories with a single set of patches each =====
You can set up multiple sets of patches at once against multiple repositories:
Update fx-team
* hg pull fx-team && hg up fx-team
Create a bookmark to base your fx-team checkin-needed patches
* hg bookmark fxteam-checkins
Import a bunch of patches against fx-team
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your fx-team checkins and add another patch to the bookmark, then push it
* hg up fxteam-checkins
* hg import <patch5>
* hg out -r . fx-team # this will be patch1, patch2, and patch5
* hg push -r . fx-team
* hg bookmark -d fxteam-checkins

===== Single repository with multiple sets of patches =====
Or have multiple sets of patches against a single repository:
Update fx-team
* hg pull fx-team && hg up fx-team
Make the first bookmark/set
* hg bookmark fxteam-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up fx-team && hg bookmark fxteam-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . fx-team # patch3 and patch4
* hg up fxteam-checkins-1 && hg out -r . fx-team # patch1 and patch2
Push the first set
* hg push -r . fx-team # pushes patch1 and patch2
Get ready to push the second set
* hg up fxteam-checkins-2
* hg rebase -d fx-team # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . fx-team # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d fxteam-checkins-1
* hg bookmark -d fxteam-checkins-2

=== Uplifts ===
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

=== Backouts ===
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* `hg backout -r <revision>`
** 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).
* `hg push -r . <tree>`

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can probably still be used (assuming you don't use `hg share` to get multiple working directories, as mq doesn't play nice with shared repos):
* Copy the backout <revision> from treeherder
* `hg qbackout -e -r <revision>`
** This should open up your editor with a pre-formed commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a && hg push -r . <tree>`

qbackout can also back out a range of commits in a single backout commit:
* `hg qbackout -e -s -r <toprevision>:<bottomrevision>`
** This will open your editor with a pre-formed commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a ** hg push -r . <tree>`
(Omit qbackout's -s flag to back out each individual revision in the range as a separate commit.)

==== Revert a backout ====
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

=== Rebasing after losing a push race ===
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

=== Recovering from mistakes ===
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

=== See what you're about to push ===
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

=== View incoming changes ===
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

Sheriffing/How To/Unified Repos

2015-02-07T00:52:36Z

KWierso: Fix range

== Unified Repos ==
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

=== Setting up the repo ===
Set up your ssh key yourself
Install Mercurial 3.2 or higher
Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* hg clone https://hg.mozilla.org/hgcustom/version-control-tools
* cd mozilla-central
* ./mach mercurial-setup
Configure mercurial as desired (do not enable the mq extension) 
Edit your global .hgrc file to add the following to the [extensions] section:
*firefoxtree = /path/to/version-control-tools/hgext/firefoxtree
The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull b2ginbound && hg pull fx-team && hg pull aurora && hg pull beta && hg pull esr31 && hg pull b2g34 && hg pull b2g32 && hg pull b2g30
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

Maybe rename the folder from "mozilla-central" to "unifiedrepo" or something to make it clear it's more than just mozilla-central?

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

With [https://bugzilla.mozilla.org/show_bug.cgi?id=1116861 bug 1116861] landed in version-control-tools, you can now use the following commands to pull from groups of repositories with a single command:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound, b2g-inbound, and fx-team branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

=== Merges ===
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, b2ginbound, fx-team, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

=== Checkin-neededs ===
This assumes we're checking things in to fx-team. Replace fx-team with another branch name as needed.

===== Single repository and single set of patches =====
Update fx-team and prepare for the patches:
* hg pull fx-team
* hg up fx-team
* hg bookmark fx-team-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all fx-team checkin-needed patches
Verify your outgoing changes:
* hg out -r . fx-team
If you haven't lost a push race:
* hg push -r . fx-team
If you lost a push race:
* hg pull fx-team
* hg rebase -d fx-team
* hg push -r . fx-team
Delete your no longer needed bookmark:
* hg bookmark -d fx-team-checkins

===== Multiple repositories with a single set of patches each =====
You can set up multiple sets of patches at once against multiple repositories:
Update fx-team
* hg pull fx-team && hg up fx-team
Create a bookmark to base your fx-team checkin-needed patches
* hg bookmark fxteam-checkins
Import a bunch of patches against fx-team
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your fx-team checkins and add another patch to the bookmark, then push it
* hg up fxteam-checkins
* hg import <patch5>
* hg out -r . fx-team # this will be patch1, patch2, and patch5
* hg push -r . fx-team
* hg bookmark -d fxteam-checkins

===== Single repository with multiple sets of patches =====
Or have multiple sets of patches against a single repository:
Update fx-team
* hg pull fx-team && hg up fx-team
Make the first bookmark/set
* hg bookmark fxteam-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up fx-team && hg bookmark fxteam-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . fx-team # patch3 and patch4
* hg up fxteam-checkins-1 && hg out -r . fx-team # patch1 and patch2
Push the first set
* hg push -r . fx-team # pushes patch1 and patch2
Get ready to push the second set
* hg up fxteam-checkins-2
* hg rebase -d fx-team # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . fx-team # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d fxteam-checkins-1
* hg bookmark -d fxteam-checkins-2

=== Uplifts ===
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision>::<bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

=== Backouts ===
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* `hg backout -r <revision>`
** 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).
* `hg push -r . <tree>`

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can probably still be used (assuming you don't use `hg share` to get multiple working directories, as mq doesn't play nice with shared repos):
* Copy the backout <revision> from treeherder
* `hg qbackout -e -r <revision>`
** This should open up your editor with a pre-formed commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a && hg push -r . <tree>`

qbackout can also back out a range of commits in a single backout commit:
* `hg qbackout -e -s -r <toprevision>:<bottomrevision>`
** This will open your editor with a pre-formed commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a ** hg push -r . <tree>`
(Omit qbackout's -s flag to back out each individual revision in the range as a separate commit.)

==== Revert a backout ====
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

=== Rebasing after losing a push race ===
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

=== Recovering from mistakes ===
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

=== See what you're about to push ===
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

=== View incoming changes ===
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

Sheriffing/How To/Unified Repos

2015-02-07T00:47:47Z

KWierso: Formatting fix

== Unified Repos ==
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

=== Setting up the repo ===
Set up your ssh key yourself
Install Mercurial 3.2 or higher
Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* hg clone https://hg.mozilla.org/hgcustom/version-control-tools
* cd mozilla-central
* ./mach mercurial-setup
Configure mercurial as desired (do not enable the mq extension) 
Edit your global .hgrc file to add the following to the [extensions] section:
*firefoxtree = /path/to/version-control-tools/hgext/firefoxtree
The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull b2ginbound && hg pull fx-team && hg pull aurora && hg pull beta && hg pull esr31 && hg pull b2g34 && hg pull b2g32 && hg pull b2g30
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

Maybe rename the folder from "mozilla-central" to "unifiedrepo" or something to make it clear it's more than just mozilla-central?

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

With [https://bugzilla.mozilla.org/show_bug.cgi?id=1116861 bug 1116861] landed in version-control-tools, you can now use the following commands to pull from groups of repositories with a single command:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound, b2g-inbound, and fx-team branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

=== Merges ===
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, b2ginbound, fx-team, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

=== Checkin-neededs ===
This assumes we're checking things in to fx-team. Replace fx-team with another branch name as needed.

===== Single repository and single set of patches =====
Update fx-team and prepare for the patches:
* hg pull fx-team
* hg up fx-team
* hg bookmark fx-team-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all fx-team checkin-needed patches
Verify your outgoing changes:
* hg out -r . fx-team
If you haven't lost a push race:
* hg push -r . fx-team
If you lost a push race:
* hg pull fx-team
* hg rebase -d fx-team
* hg push -r . fx-team
Delete your no longer needed bookmark:
* hg bookmark -d fx-team-checkins

===== Multiple repositories with a single set of patches each =====
You can set up multiple sets of patches at once against multiple repositories:
Update fx-team
* hg pull fx-team && hg up fx-team
Create a bookmark to base your fx-team checkin-needed patches
* hg bookmark fxteam-checkins
Import a bunch of patches against fx-team
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your fx-team checkins and add another patch to the bookmark, then push it
* hg up fxteam-checkins
* hg import <patch5>
* hg out -r . fx-team # this will be patch1, patch2, and patch5
* hg push -r . fx-team
* hg bookmark -d fxteam-checkins

===== Single repository with multiple sets of patches =====
Or have multiple sets of patches against a single repository:
Update fx-team
* hg pull fx-team && hg up fx-team
Make the first bookmark/set
* hg bookmark fxteam-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up fx-team && hg bookmark fxteam-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . fx-team # patch3 and patch4
* hg up fxteam-checkins-1 && hg out -r . fx-team # patch1 and patch2
Push the first set
* hg push -r . fx-team # pushes patch1 and patch2
Get ready to push the second set
* hg up fxteam-checkins-2
* hg rebase -d fx-team # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . fx-team # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d fxteam-checkins-1
* hg bookmark -d fxteam-checkins-2

=== Uplifts ===
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision><bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

=== Backouts ===
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* `hg backout -r <revision>`
** 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).
* `hg push -r . <tree>`

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can probably still be used (assuming you don't use `hg share` to get multiple working directories, as mq doesn't play nice with shared repos):
* Copy the backout <revision> from treeherder
* `hg qbackout -e -r <revision>`
** This should open up your editor with a pre-formed commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a && hg push -r . <tree>`

qbackout can also back out a range of commits in a single backout commit:
* `hg qbackout -e -s -r <toprevision>:<bottomrevision>`
** This will open your editor with a pre-formed commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a ** hg push -r . <tree>`
(Omit qbackout's -s flag to back out each individual revision in the range as a separate commit.)

==== Revert a backout ====
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

=== Rebasing after losing a push race ===
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

=== Recovering from mistakes ===
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

=== See what you're about to push ===
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

=== View incoming changes ===
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

Sheriffing/How To/Unified Repos

2015-02-07T00:43:45Z

KWierso: Formatting fix

== Unified Repos ==
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

=== Setting up the repo ===
Set up your ssh key yourself
Install Mercurial 3.2 or higher
Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* hg clone https://hg.mozilla.org/hgcustom/version-control-tools
* cd mozilla-central
* ./mach mercurial-setup
Configure mercurial as desired (do not enable the mq extension) 
Edit your global .hgrc file to add the following to the [extensions] section:
*firefoxtree = /path/to/version-control-tools/hgext/firefoxtree
The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull b2ginbound && hg pull fx-team && hg pull aurora && hg pull beta && hg pull esr31 && hg pull b2g34 && hg pull b2g32 && hg pull b2g30
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

Maybe rename the folder from "mozilla-central" to "unifiedrepo" or something to make it clear it's more than just mozilla-central?

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

With [https://bugzilla.mozilla.org/show_bug.cgi?id=1116861 bug 1116861] landed in version-control-tools, you can now use the following commands to pull from groups of repositories with a single command:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound, b2g-inbound, and fx-team branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

=== Merges ===
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, b2ginbound, fx-team, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

=== Checkin-neededs ===
This assumes we're checking things in to fx-team. Replace fx-team with another branch name as needed.

Update fx-team and prepare for the patches:
* hg pull fx-team
* hg up fx-team
* hg bookmark fx-team-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all fx-team checkin-needed patches
Verify your outgoing changes:
* hg out -r . fx-team
If you haven't lost a push race:
* hg push -r . fx-team
If you lost a push race:
* hg pull fx-team
* hg rebase -d fx-team
* hg push -r . fx-team
Delete your no longer needed bookmark:
* hg bookmark -d fx-team-checkins

You can set up multiple sets of patches at once against multiple repositories:
Update fx-team
* hg pull fx-team && hg up fx-team
Create a bookmark to base your fx-team checkin-needed patches
* hg bookmark fxteam-checkins
Import a bunch of patches against fx-team
* hg import <patch1>
* hg import <patch2>
Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
Go back to your fx-team checkins and add another patch to the bookmark, then push it
* hg up fxteam-checkins
* hg import <patch5>
* hg out -r . fx-team # this will be patch1, patch2, and patch5
* hg push -r . fx-team
* hg bookmark -d fxteam-checkins

Or have multiple sets of patches against a single repository:
Update fx-team
* hg pull fx-team && hg up fx-team
Make the first bookmark/set
* hg bookmark fxteam-checkins-1
* hg import <patch1>
* hg import <patch2>
Make the second set
* hg up fx-team && hg bookmark fxteam-checkins-2
* hg import <patch3>
* hg import <patch4>
See what's going to be pushed in each
* hg out -r . fx-team # patch3 and patch4
* hg up fxteam-checkins-1 && hg out -r . fx-team # patch1 and patch2
Push the first set
* hg push -r . fx-team # pushes patch1 and patch2
Get ready to push the second set
* hg up fxteam-checkins-2
* hg rebase -d fx-team # Rebase the second set onto the now-pushed first set
And push it
* hg push -r . fx-team # pushes patch3 and patch4
Delete the now-unneeded bookmarks
* hg bookmark -d fxteam-checkins-1
* hg bookmark -d fxteam-checkins-2

=== Uplifts ===
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision><bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

=== Backouts ===
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* `hg backout -r <revision>`
** 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).
* `hg push -r . <tree>`

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can probably still be used (assuming you don't use `hg share` to get multiple working directories, as mq doesn't play nice with shared repos):
* Copy the backout <revision> from treeherder
* `hg qbackout -e -r <revision>`
** This should open up your editor with a pre-formed commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a && hg push -r . <tree>`

qbackout can also back out a range of commits in a single backout commit:
* `hg qbackout -e -s -r <toprevision>:<bottomrevision>`
** This will open your editor with a pre-formed commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a ** hg push -r . <tree>`
(Omit qbackout's -s flag to back out each individual revision in the range as a separate commit.)

==== Revert a backout ====
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

=== Rebasing after losing a push race ===
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

=== Recovering from mistakes ===
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

=== See what you're about to push ===
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

=== View incoming changes ===
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

Sheriffing/How To/Unified Repos

2015-02-07T00:40:42Z

KWierso: Add more examples for checkin-neededs

== Unified Repos ==
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

=== Setting up the repo ===
Set up your ssh key yourself
Install Mercurial 3.2 or higher
Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* hg clone https://hg.mozilla.org/hgcustom/version-control-tools
* cd mozilla-central
* ./mach mercurial-setup
Configure mercurial as desired (do not enable the mq extension) 
Edit your global .hgrc file to add the following to the [extensions] section:
*firefoxtree = /path/to/version-control-tools/hgext/firefoxtree
The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull b2ginbound && hg pull fx-team && hg pull aurora && hg pull beta && hg pull esr31 && hg pull b2g34 && hg pull b2g32 && hg pull b2g30
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

Maybe rename the folder from "mozilla-central" to "unifiedrepo" or something to make it clear it's more than just mozilla-central?

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

With [https://bugzilla.mozilla.org/show_bug.cgi?id=1116861 bug 1116861] landed in version-control-tools, you can now use the following commands to pull from groups of repositories with a single command:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound, b2g-inbound, and fx-team branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

=== Merges ===
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, b2ginbound, fx-team, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

=== Checkin-neededs ===
This assumes we're checking things in to fx-team. Replace fx-team with another branch name as needed.

Update fx-team and prepare for the patches:
* hg pull fx-team
* hg up fx-team
* hg bookmark fx-team-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all fx-team checkin-needed patches
Verify your outgoing changes:
* hg out -r . fx-team
If you haven't lost a push race:
* hg push -r . fx-team
If you lost a push race:
* hg pull fx-team
* hg rebase -d fx-team
* hg push -r . fx-team
Delete your no longer needed bookmark:
* hg bookmark -d fx-team-checkins

You can set up multiple sets of patches at once against multiple repositories:
# Update fx-team
* hg pull fx-team && hg up fx-team
# Create a bookmark to base your fx-team checkin-needed patches
* hg bookmark fxteam-checkins
# Import a bunch of patches against fx-team
* hg import <patch1>
* hg import <patch2>
# Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
# Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
# See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
# Go back to your fx-team checkins and add another patch to the bookmark, then push it
* hg up fxteam-checkins
* hg import <patch5>
* hg out -r . fx-team # this will be patch1, patch2, and patch5
* hg push -r . fx-team
* hg bookmark -d fxteam-checkins

Or have multiple sets of patches against a single repository:
# Update fx-team
* hg pull fx-team && hg up fx-team
# Make the first bookmark/set
* hg bookmark fxteam-checkins-1
* hg import <patch1>
* hg import <patch2>
# Make the second set
* hg up fx-team && hg bookmark fxteam-checkins-2
* hg import <patch3>
* hg import <patch4>
# See what's going to be pushed in each
* hg out -r . fx-team # patch3 and patch4
* hg up fxteam-checkins-1 && hg out -r . fx-team # patch1 and patch2
# Push the first set
* hg push -r . fx-team # pushes patch1 and patch2
# Get ready to push the second set
* hg up fxteam-checkins-2
* hg rebase -d fx-team # Rebase the second set onto the now-pushed first set
# And push it
* hg push -r . fx-team # pushes patch3 and patch4
# Delete the now-unneeded bookmarks
* hg bookmark -d fxteam-checkins-1
* hg bookmark -d fxteam-checkins-2

=== Uplifts ===
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision><bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

=== Backouts ===
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* `hg backout -r <revision>`
** 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).
* `hg push -r . <tree>`

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can probably still be used (assuming you don't use `hg share` to get multiple working directories, as mq doesn't play nice with shared repos):
* Copy the backout <revision> from treeherder
* `hg qbackout -e -r <revision>`
** This should open up your editor with a pre-formed commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a && hg push -r . <tree>`

qbackout can also back out a range of commits in a single backout commit:
* `hg qbackout -e -s -r <toprevision>:<bottomrevision>`
** This will open your editor with a pre-formed commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a ** hg push -r . <tree>`
(Omit qbackout's -s flag to back out each individual revision in the range as a separate commit.)

==== Revert a backout ====
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

=== Rebasing after losing a push race ===
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

=== Recovering from mistakes ===
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

=== See what you're about to push ===
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

=== View incoming changes ===
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

Sheriffing/How To/Unified Repos

2015-02-07T00:19:02Z

KWierso: More advanced checkin-needed styles

== Unified Repos ==
* http://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/firefoxtree.html

=== Setting up the repo ===
Set up your ssh key yourself
Install Mercurial 3.2 or higher
Make a copy of your .hgrc file for safekeeping and delete the original
* hg clone https://hg.mozilla.org/mozilla-central
* hg clone https://hg.mozilla.org/hgcustom/version-control-tools
* cd mozilla-central
* ./mach mercurial-setup
Configure mercurial as desired (do not enable the mq extension) 
Edit your global .hgrc file to add the following to the [extensions] section:
*firefoxtree = /path/to/version-control-tools/hgext/firefoxtree
The following will pull all (or at least most) of the branches sheriffs need to have on hand:
* hg pull inbound && hg pull b2ginbound && hg pull fx-team && hg pull aurora && hg pull beta && hg pull esr31 && hg pull b2g34 && hg pull b2g32 && hg pull b2g30
If you need other branches, you can find their names in the [https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py firefoxtree extension source].

You should now have everything set up for proper use! 

Maybe rename the folder from "mozilla-central" to "unifiedrepo" or something to make it clear it's more than just mozilla-central?

The `hg fxheads` command should list references to each of the relevant branch names, and the current revision and commit message for each.

With [https://bugzilla.mozilla.org/show_bug.cgi?id=1116861 bug 1116861] landed in version-control-tools, you can now use the following commands to pull from groups of repositories with a single command:
* hg pull fxtrees # this will pull from all branches listed with the fxheads command
* hg pull integration # this will pull from the mozilla-inbound, b2g-inbound, and fx-team branches
* hg pull releases # this will pull from pretty much every release branch (FYI: including old, unused branches)

=== Merges ===
This assumes you have your unified repo all set up so that `hg fxheads` lists each of central, b2ginbound, fx-team, and inbound.

To merge a specific non-tip <revision> from mozilla-inbound to mozilla-central:
# hg pull central
# hg pull inbound
# hg up central
# hg merge -r <revision>
# hg commit -m "Merge mozilla-inbound to mozilla-central a=merge"
# hg push -r . central

To merge mozilla-central into mozilla-inbound:
# hg pull central
# hg pull inbound
# hg up inbound
# hg merge central
# hg commit -m "Merge mozilla-central to mozilla-inbound a=merge"
# hg push -r . inbound

* If the `hg merge central` command results in "abort: nothing to merge", you should instead use `hg update -r <mozilla-central's tip revision>` to do a non-merging update, then you can do `hg push -r . inbound` to push it as usual.

=== Checkin-neededs ===
This assumes we're checking things in to fx-team. Replace fx-team with another branch name as needed.

Update fx-team and prepare for the patches:
* hg pull fx-team
* hg up fx-team
* hg bookmark fx-team-checkins
Import the patches:
* hg import https://link.to/correct/checkin-needed.patch
* Repeat ^ as needed for all fx-team checkin-needed patches
Verify your outgoing changes:
* hg out -r . fx-team
If you haven't lost a push race:
* hg push -r . fx-team
If you lost a push race:
* hg pull fx-team
* hg rebase -d fx-team
* hg push -r . fx-team
Delete your no longer needed bookmark:
* hg bookmark -d fx-team-checkins

You can set up multiple sets of patches at once (either multiple sets against a single repository or one set for multiple repositories):
# Update fx-team
* hg pull fx-team && hg up fx-team
# Create a bookmark to base your fx-team checkin-needed patches
* hg bookmark fxteam-checkins
# Import a bunch of patches against fx-team
* hg import <patch1>
* hg import <patch2>
# Update inbound and make a bookmark for inbound patches
* hg pull inbound && hg up inbound && hg bookmark inbound-checkins
# Import some patches against inbound
* hg import <patch3>
* hg import <patch4>
# See what you'd be pushing to inbound and push it
* hg out -r . inbound # this will only show patch3 and patch4
* hg push -r . inbound # this only pushes patch3 and patch4
* hg bookmark -d inbound-checkins # delete inbound's checkin bookmark as it's not needed
# Go back to your fx-team checkins and add another patch to the bookmark, then push it
* hg up fxteam-checkins
* hg import <patch5>
* hg out -r . fx-team # this will be patch1, patch2, and patch5
* hg push -r . fx-team
* hg bookmark -d fxteam-checkins

=== Uplifts ===
If branch-specific patches are posted, follow the checkin-needed instructions above, importing the patches onto the release branch.

If you're uplifting directly from an m-c checkin to aurora:

Pull and update to prepare for the uplifts:
* hg pull central
* hg pull aurora
* hg up aurora
Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:
* hg graft --edit -r <revision>
Repeat the previous step as needed for all uplifts as needed.
Verify the outgoing changes and push:
* hg out -r . aurora
* hg push -r . aurora

You can graft a range of commits at once if that's easier:
* hg graft -r <toprevision><bottomrevision>

Read the documentation for [https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/unifiedrepo.html#uplifting-backporting-commits graft] for further help.

=== Backouts ===
Better tools are coming:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1117632
* https://bugzilla.mozilla.org/show_bug.cgi?id=1121211
 

The standard backout command makes backing out revisions more difficult than it should, as it won't pre-fill the backout commit message with a bug number:
* Copy backout <revision> from treeherder, note the bug <number>, and remember the <reason>
* `hg backout -r <revision>`
** 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).
* `hg push -r . <tree>`

[https://hg.mozilla.org/hgcustom/version-control-tools/file/4e7ab9638cf0/hgext/qbackout qbackout] can probably still be used (assuming you don't use `hg share` to get multiple working directories, as mq doesn't play nice with shared repos):
* Copy the backout <revision> from treeherder
* `hg qbackout -e -r <revision>`
** This should open up your editor with a pre-formed commit message like "Backed out <revision> (bug <number>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a && hg push -r . <tree>`

qbackout can also back out a range of commits in a single backout commit:
* `hg qbackout -e -s -r <toprevision>:<bottomrevision>`
** This will open your editor with a pre-formed commit message like "Backed out <toprevision>,<anymiddlerevisions>,<bottomrevision> (bug <number>,any other bug <numbers>)". Add in the <reason> and possibly "CLOSED TREE" to get around a closure hook.
* `hg qfin -a ** hg push -r . <tree>`
(Omit qbackout's -s flag to back out each individual revision in the range as a separate commit.)

==== Revert a backout ====
* https://mozilla-version-control-tools.readthedocs.org/en/latest/hgmozilla/common.html#revive-a-commit-that-was-backed-out

=== Rebasing after losing a push race ===
This assumes you have commits you're attempting to push to mozilla-inbound when you lose a push race with someone. Change `inbound` to the correct branch name as needed.

* hg pull inbound
* hg rebase -d inbound
* hg push -r . inbound

=== Recovering from mistakes ===
<big>WARNING:</big> This will strip out any commits that haven't been pushed to the remote repositories, regardless of what branch/label/tag those commits are on. (So if you have local changes on inbound and run this command to strip something bad on fx-team, both inbound and fx-team will be stripped.) Only do this if you don't care about any of those commits!
* hg strip 'not public()'

=== See what you're about to push ===
`hg out` without any flags added will show you a LOT of unrelated commits. To see just what you'll be pushing to a given branch, use `hg out -r . <branch>`
* hg out -r . inbound
** This will only display the things you're about to push to the inbound branch

=== View incoming changes ===
Since your unified repo will likely have all changesets from the various branches pulled locally, `hg in <somebranch> -r <somerev>` will likely not help you see what would be pulled into your current branch from <somebranch> up to that <somerev>.
Instead, you can use the following to print out the equivalent. Say you want to see what would be merged onto mozilla-central from b2g-inbound's revision ca142ec8ba0f:

Make sure m-c is fully up to date:
* hg pull central
* hg up central
Get all of b2g-inbound's changesets:
* hg pull b2ginbound
Do a preview of the merge without actually performing the merge:
* hg merge -r ca142ec8ba0f -P
This will print out everything on b2g-inbound (up to and including revision ca142ec8ba0f) that is not already on mozilla-central.

ReleaseEngineering/How To/Trigger arbitrary jobs

2015-02-06T01:16:41Z

KWierso: Using "--revision" didn't work for me locally. "--rev" did, though.

* This script hits the API that zeller, catlee and hwine made available:
** http://blog.johnzeller.com/triggering-of-arbitrary-buildstests-is-now-possible/

Disclaimer: use this carefully as you could cause a lot of trouble.

= Setup =
<pre>
git clone https://github.com/armenzg/mozilla_ci_tools.git
python setup.py develop (or install)
python scripts/trigger.py --help
</pre>

NOTE: We can probably improve this by adding console_scripts to setup.py and make it an installable script.

= File issues =
File issues under https://github.com/armenzg/mozilla_ci_tools/issues.
armenzg is currently the main maintainer.

= Usage =
NOTE: You can now trigger jobs without having to find the installer and tests urls. 
NOTE: This script will now trigger the associated build if there is no available completed build. 

Run it like this:
<pre>
python scripts/trigger.py \
--rev 6610f4646b3c --repo-name try --buildername "Android 2.2 Debug try build"
</pre>

= Hacks =
* You can run a test/talos job against:
** your own installer located at any web-host
** your own tests.zip located at any web-host
** This allows you to hack a tests.zip on your people account and zip it back
*** use it with zip -rq9D && chmod 644
* You also don't need a build to happen on a revision to trigger a test/talos job

= Solved issues =
* There's some logic to prevent you from triggering jobs against non-existing builds/test.zip (to some extent)

= Known issues =
* You can attempt to trigger a revision that doesn't exist
* You can try to trigger a builder that doesn't exist
* You can be tempted to write a script to run a lot of jobs
** Remember that these are shared production resources
* We could have a web page to make this easier