Sheriffing/How To/Landing patches

Sheriffs have the responsibility for landing checkin-needed patches on behalf of others who do not have the needed commit access to do so themselves or those who do not have the ability to watch their pushes afterwards.
Usually, patches should be landed after the merges and after the nightly builds started running. Of course, it can also be done when requested.

Bugzilla queries for patches requiring check-in

• Only patches for mozilla-central: Bugs with checkin-needed or checkin? requests set excluding non-core components in comm-central and NSS and NSPR
  • This is now available as a shared saved search for anyone with editbugs permissions on bugzilla. Go here and search for "checkin-needed-core" to find it in the list, and you can add it to Bugzilla's footer.
• Also including patches for other trees, e.g. comm-central: Bugs with checkin-needed or checkin? requests set in all components

How to land check-in needed patches

• Verify that the patch has proper review before doing anything else
  • Module information
• Saving the attachment from the bug.
• Apply the patch to the appropriate repository using hg import (preferred) or patch.
  • For almost all patches, the appropriate repository is mozilla-inbound.
• If the patch does not apply cleanly, you can try to rebase. If that doesn't solve the issue, your best course of action is to remove the checkin-needed request and ask the developer to post an updated patch for check-in. If you understand the code very well or the conflicts are extremely trivial, you can try to resolve the conflicts yourself, but note that YOU are now on the hook for this patch too.
• Once the patch applies cleanly, verify that the commit information is correct:
  • Author (use the information from their Bugzilla account if needed)
  • Bug number
  • Commit message (keeping in mind that the commit message should be a brief description of what the patch is doing)
    • Format should be something like "Bug 123456 - Add a null check to XYZ to avoid a crash. r=somebody"
• If a patch is missing commit information, remind the patch author to include it for future patches with a link to the Mercurial FAQ page that describes how to set it.

The patches can be landed in 2 ways: Automatically, from mozreview – and the patches will land on AUTOLAND Manually, from the console – and the patches will land on INBOUND

Landing patches via mozreview (reviewboard) - Autoland

• These patches will have an additional section on the bug, right above “Attachments”, called “MozReview Requests”

• Click the link under “MozReview Requests” and you will be redirected to another page, from where the commit can be landed:

• Click on the dropdown menu from Automation, and then click on Land Commits.

Note: If you cannot land the patch from GUI:

1. Comment this message on the bug: “The patch doesn't meet the review requirements in MozReview needed for Autoland to push it - see http://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview/autoland.html#landing-commits“
2. Needinfo the developer
3. Remove the checkin-needed tag

Landing patches from the console - Inbound

We will have to identify the person that added the patch, and the one that reviewed the patch. For this, you can use: https://wiki.mozilla.org/Modules/All or https://phonebook.mozilla.org/ or https://mozillians.org/en-US/

These are the steps that you should follow:

1. cd mozilla-unified
2. hg pull inbound
3. hg update inbound
4. hg qimport bz://<bugnumber> //to import the patches from the chosen bug
5. hg qseries //check the patches in the queue
6. hg qpush //apply patch. Use hg qpush -a if there are multiple patches
7. hg log //check the commit message
8. If in hg log, the name or e-mail of the reviewer are not correct, use hg qref –u “Name <email>”
9. hg qref -e //to add the reviewer and/ or edit the commit message
10. hg qfinish -a //turn all into permanent changesets
11. hg push -r . inbound

Note: If you get the following error when pushing to inbound: "abort: push creates new remote head ..." run:

1. hg pull --rebase inbound
2. hg push -r . inbound

Deleting a patch from the tip

If you encounter any errors when applying a patch, you will have to:

• delete the patch from the queue
• needinfo the dev
• delete the checkin-needed tag
• leave a comment on the bug with the issue that stopped you from landing the bug.

And furthermore to :

• hg qpop
• hg qdelete <patch_name>
• hg purge (--only if there are .rej files)
• hg update -C

Relanding a revision

If requested, one or more revisions can be relanded after, for example, being backed out.

1. hg graft -er/-esr <revision number> OR <revision>::<revision>
2. hg import <revision link>
3. hg commit --amend //to update the commit message'
4. hg push -r . <tree>

Landing bugs with multiple patches, out of which one is a zip file

If there are other patches, except the zip file, do the following:

1. hg qimport all the patches UP TO the zip file
2. hg push -a // if there are multiple patches
3. hg qfinish -a
4. hg histedit // if you need to edit the reviewers
5. hg finish -a

Then:

1. Go to the bug in your VM, download the zip file, then unzip it (in your home directory to be easier)
2. Go to your console and run hg qimport ~/bug.patch // bug.patch is the file from the zip; ~/ = home = path where you extracted the file
3. hg qpush
4. hg qref -e // to edit reviewer when it's just one patch
5. hg finish -a
6. hg qimport bz://bug // import the rest of the missing patches, the ones that are not zip or other formats
7. hg qpush -a
8. hg qfinish -a
9. hg histedit // edit reviewers if necessary
10. hg push -r . inbound

What to do in case you forget to update to inbound before importing patches

Landing Patches (rebasing your revision to the right tree in case you forgot to update to inbound before importing patches) Example: Let's say you are on the top of Autoland and you want to land some patches on Inbound, but you forgot to update to inbound, so you already imported a few patches and you realize you are on Autoland instead of inbound. What to do in order to rebase to the right tree:

1. hg log -fr. // to force show the log and check how many revisions you have created - how many patches you have imported. Also you will need this later for the revision.

1. hg pull inbound
2. hg rebase -s <revision/changeset number of the bottom most patch> -d inbound

Note: revision number of the bottom most patch = in the case above is 19212c6d7051, we only need the second string of characters from the changeset. -s = source; -d = destination Good to know: When running this command, hg will move(cut) all the patches from Autoland to Inbound, starting from the source (e.g:19212c6d7051) to the last patch. (top most patch).

1. hg log // to check if the commands had the desired effect
2. hg update tip // this command will activate the rebase, will make sure that the changesets that were imported from the other tree are going to be in your tip for this specific tree. In this case inbound.

1. hg out -r . inbound // check to see that the two patches rebased to inbound and are active in the tip
2. Once the patches are where they should, you can go ahead and push.
3. hg push -r . inbound