Transitioning RelEng Status


From time to time, folks move in and out of the Release Engineering role. As they do so, access to various systems should be granted and removed [*] .

When someone moves into the organization, permissions should be granted as needed to perform the various tasks. While permissions are granted only as needed, there are also minimum requirements for the permissions. For example, some permissions may only be available to someone who is both a member of the RelEng team and an employee.

The table below lists all the permissions, and which requirements are required to have that permission. When a person no longer has a specific status, all permissions which require that status need to be check and revoked. (Refer to the day one page for details on permissions.) Legend:

RE: Release Engineering team member
Emp: Mozilla Corporation employee
CM: Contributing community Member
RE Emp CM Permission
password changes:
X     access to releng password files [1]
X X   #mozbuild password [2]
X     bouncer [3]
X     balrog [3]
X     treestatus [3]
X     releng etherpad account [3]
X     cltbld & root slave farm password
X     releng puppet masters
compute resources
X X X AWS console access
X X   releng LDAP bits (IT bug) releng, vpn_releng, RelengWiki, & SysAdminWiki
X     unassign any resources in slavealloc
X     RelEng machine access e.g. cruncher, stage, buildbot masters, etc. [4]
miscellaneous systems
X X   github ownership roles [6]
X special access [5]
X X X github write access (review)
X     releng/build bugzilla group access [7]
X X   Google Drive RelEng folder access
X X   Release google calendar
X X   Release google group
X X   Release Trello group
X     other Google Drive documents [8]
X     re-assign bugs
X     named contact in Nagios escalation chain
X     Allowed to merge to puppet production [3]

Detailed Instructions

Password List


Almost all passwords are now shared via gpg encrypted files. To get a list of passwords shared with a user, use the “scripts/who_knows_what” script to identify passwords that should be changed. Also, add the departing user’s id to the “scripts/alumni.json” file.


access to the repo requires both membership in both the vpn_git_internal (or vpn_releng) and either (relops or releng).


To change the password on an IRC channel where you have ops permissions:

  • Make sure user is not in #mozbuild, a kick or ban is sometimes necessary (due to auto-reconnect)
  • /msg chanserv set #mozbuild mlock +k newpass
[3](1, 2, 3, 4, 5)

Bouncer: change via bounceradmin.m.c

Balrog: go to permissions from

Treestatus: from users page.

Puppet Merge: commit update to hook <> and request deploy.

Compute Resources

In addition to password changes governing access to compute resources, a scan of systems must be made to ensure no processes or cron jobs have been left running.

[4]These are systems where the user is granted access via their ssh key, either to their user specific account, or to a shared account (such as cltbld). However, these systems have keys deployed via the RelEng puppet servers, which only sync with MoCo ldap via a cron job.

Miscellaneous Systems

These systems are unique, so you may need to refer to other documentation for instructions.

[5]There are some hand maintained white lists for push permissions to certain branches. (E.g. puppet production) Changes need to be approved by a RelEng/RelOps manager.
[6]For now, the accounts to check are mozilla & mozilla-b2g. Note that we’re only discussing the ownership role here on RelEng owned resources. If the person has ownership rights to repositories due to their contributor status, that does not change.
[7]This bugzilla group can cause some confusion for folks transitioning out of MoCo but remaining a RelEng contributor. Perform on the admin page.
[8]To find documents where exceptional access has been granted, use the script at



Unlike most of Mozilla development, some Release Engineering roles are only available to employees for various legal or contractual reasons. That leads to layers of access:

Folks directly performing tasks which require knowledge of how Release Engineering systems work and interact.
MoCo Emp:
Folks who have a contractual arrangement with Mozilla that may be required for access to certain restricted systems and data.
Folks who have valid committer’s agreement on file.