$ hg qref --message "-b d -p linux64 -u all -t none"
$ hg push -f try

$ hg push mozilla-inbound

Very manual process

Developer has to be around to land on inbound

Reviewer wastes time with style nits

The "A" stands for "automation"

(and "awesome")

(but they don't have a cool logo)

ending up eventually in mozilla-inbound

• Static analysis
• Uplift analysis
• Regression analysis
• Try run
  • with intelligent test selection
• Intelligent (human) reviewer selection

Robots leave reviews with open issues:

Reviewer time is very valuable

No action needed by author

Automatic try run before landing

No integration branches: linear history

Landings resume after tree closure

Landings can be spread out through the day

Automatic annotation of reviewers, link to MozReview request, etc.

Syntax highlighting, including trailing spaces

Moved code

Interdiffs that actually work

Commits are pushed to a review repo as they would be pushed to try or the repository of record

Three categories of benefits:

• operations on commits
• movement of commits
• improvements to workflow

Some things are easier to do in commits within the context of the whole repository than in isolated, contextless patches

Actions can be done by the review server based on in-tree metadata

• Automatic bug filing
• Automatic reviewer selection

Automatic code-style analysis and/or reformatting saves reviewer time

Reviewers edit code directly (annotations/suggestions) rather than describing changes

Automatically set commit metadata: link to review, list of reviewers

Pushing to the review repo is the same as pushing to repo of record. No more exporting patches

Moving commits around is much easier than applying patches

Pulling patches into your local working environment is the same as pulling from the repo of record. No more importing patches—and no more bitrot in testing.

And of course, autoland

Encourages (or at least does not discourage) microcommits: small, independent change sets

Makes reviewing easier and faster

Allows partial landings

Avoids bitrot

Chopping work into small pieces leads to less potential instability (not everything landing at once)

Rewards developers in the form of progress

Detect when commits can't cleanly apply

Detect when multiple commits touch the same files

Anticipate problems

We're constantly improving it