Release Management/Onboarding

Welcome to Release Management! Here is a list of accounts to set up, tools to check out, and any other details we can think of to help you start getting yourself set up.

Account Permissions

You'll want to make sure you have the necessary permissions to do the following and some will take longer than others to achieve so start early.

Bugzilla

• Create a Bugzilla account.
• File a bug to request for your bugzilla account to be added to the mozilla-next-drivers and mozilla-stable-branch-drivers groups in order to set tracking flags (eg: bug 962151). Make sure you also have the edit-bugs and canconfirm permissions.
• You can see security sensitive bugs if someone CCs you into the bug, or if you eventually join the security group list. Security permission comes later. See Client Security Bug Access Policy mana page for additional info on requesting access.

Internal Documentation

• Ask your manager for the permissions to access the team Google drive folder.

VPN

Configure your system to access to the Mozilla VPN in order to get access to internal tools like Ship-It.

Documentation:

• To get access to Mozilla OpenVPN, place a request for Viscosity for Mac/PC on the JSM portal and follow the Mac/PC installation instructions.
• Viscosity Install for Windows
• Viscosity Install for Mac.
• OpenVPN Install for Linux

Ship It and Balrog

Ship It is available behind our VPN, as is balrog's admin UI.

File a bug (Infrastructure & Operations::Infrastructure:LDAP) to be added to the shipit_firefox, shipit_mobile, vpn_cloudops_shipit, balrog and vpn_balrog groups. Example: bug 1469544

Once you are using the Mozilla VPN, you can access the application and use your LDAP account to log in.

Ubuntu Snaps

We build and publish a Firefox Ubuntu snap package ourselves.

Release Engineering has some documentation on how we create and push snaps.

The Firefox Snaps Dashboard requires a Ubuntu One developer account and this account to be associated with your @mozilla.com email address. Your Ubuntu One account should have 2FA activated (Ubuntu Specific instructions).

Once you have set up your Ubuntu One account and registered as a developer on Snapcraft with this account, ask Release Engineering to send you an invite to manage Firefox snaps. An unfinished stab at defining the Snap uploading process is in bug 1467261. Anyone who is on the list at https://dashboard.snapcraft.io/snaps/firefox/collaboration/ can add someone else to the list.

Samsung Store

You will need to ask for access to the Samsung Store

Release Notes

Request admin access to https://nucleus.mozilla.org by filing two bugs.

First, one to get the Nucleus site added to your SSO account in Infrastructure & Operations::Infrastructure: SSO, Example: bug 1351680.

The second bug is to be added as admin in the Web App Websites::Nucleus. Example: bug 1135186

Google Play Console

File a bug in the App Stores component, https://bugzilla.mozilla.org/enter_bug.cgi?product=App%20Stores Example: https://bugzilla.mozilla.org/show_bug.cgi?id=1724432

Socorro/Stability (crash-stats)

• This blog post provides an overview of Mozilla's crash reporting pipeline.
• https://crash-stats.mozilla.org/ should be accessible for general use. If you require enhanced permissions (typically to access protected data, file a bug in Socorro | General.
• there is more crash info at https://mozilla.cloud.looker.com/dashboards/918?Channel=release&OS+Name=&Ten+Percent+Sample=Yes But no special account is needed.

Github

Some of our tools are developed on Github, some Firefox features are also developped on Github and many teams use Github for development but also documentation, blogging, project management…

• if you don't have an account, get one.
• Ask your manager to add you to the Release management team on Github (https://github.com/orgs/mozilla/teams/release-management/members)

Please note that although you can use Github to file bugs in Bugzilla, you should not use it as your work account because Github accounts on bugzilla can't access security and internal bugs.

Repositories

• hg commit access (scm_level3) -- read https://www.mozilla.org/hacking/committer/, fill out a committer agreement, file a bug (eg: bug 738713 except you'll request commit access, not elevation of current permissions). For this, you will need two owners or peers for a core hg module to vouch for you as described in Commit Access Policy. (later)
• Example of asking for level 1 commit access (which lets you push changes to the try server): bug 1116226. This is good to start with to get your SSH key and committer agreement set up. (earlier)
• Socorro permissions: bug 1229732

PTO calendar

Ask your manager to give you access to the Release Management PTO calendar where all release managers indicate when they are on PTO.

Other

• This wiki! Create an account and update the team members page.
• Once you are familiar with the release checklists, it will be extremely useful to read this documentation on what each step means since the checklists are shorthanded
• A lot of names will be thrown around the first couple of months, here is a list of common definitions.
• Things to Bookmark
  • Bugzilla Queries
  • Current Firefox trains: https://fx-trains.herokuapp.com

Communication Channels

Release Calendar

This page describes our release schedule: Firefox Release Calendar. You should add these to your regular Google calendar so you can easily see the state of any release. Click through on the links below and then hit the + button at bottom right to add this to your Mozilla Google calendar.

• This is the basic public calendar with release dates: https://www.google.com/calendar/embed?src=mozilla.com_2d37383433353432352d3939%40resource.calendar.google.com
• This is the release manager team with tons of detail: https://www.google.com/calendar/embed?src=bW96aWxsYS5jb21fZGJxODRhbnI5aTh0Y25taGFiYXRzdHY1Y29AZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ - This is really helpful for the first managed release cycle.

E-Mail

Note that some of these mailing lists need approval from an administrator.

Our team list

• release-mgmt@mozilla.com: Discussions about releases, schedule…

Other useful lists You'll need to manually subscribe to:

• release-drivers
• release-signoff
• Release-mgmt
• dev-platform
• Enterprise
• Stability
• Announce
• security-group Check out the policy for getting added to the security-group list.
• Funstuff

Websites

• Crash reports

Matrix

We hang out in the #release-drivers:mozilla.org and #releaseduty:mozilla.org channels.

The following can also be useful:

• #developers:mozilla.org
• #firefox-ci:mozilla.org
• #sheriffs:mozilla.org

Slack

Mozilla Slack, you can login with sso.

• release-drivers - release related discussions
• qa-coordination - QE team channel
• release-coordination - Cross functional coordination room during a release
• triage-and-tracking - All things bugzilla
• release-notes - coordination with release notes stakeholders, marketing and writers
• moco - backchannel for meetings
• firefox - firefox development room
• planning- backchannel for weekly Cross Functional Meeting
• fx-weekly-digest- Where the weekly digest is posted and updated
• release-mgmt- Relman team channel

Meetings

As a release manager, you will need to attend recurrent meetings, here is the list:

Tuesday:

• 1st Channel meeting

Wednesday

• Our Team meeting

Thursday

• 2nd Channel meeting

Ask your manager and colleagues to invite you to these meetings.

EtherPad

EtherPad is a great tool for dynamic collaboration during meetings, brainstorming, or other times when you need to collaborate:

• https://pad.mozilla.org/ for general use
• https://pad.mozilla.org/p/channel-meeting for release information

Pastebin

There's a local pastebin instance at https://paste.mozilla.org/, so you don't need to paste multi-lines into a channel. You can use mach pastebin to paste from a terminal.

Planet

Add a bug similar to bug 605709 to get your blog syndicated on https://planet.mozilla.org. You can choose to send every post, or create a feed for a custom tag (eg: 'mozilla'). Having your blog syndicated to planet is a great channel for announcing new features (along with tweeting and posting to newsgroups).

Software

Firefox

1. Please download & install Firefox nightly, beta, release, and devedition
2. Create new profiles for each version + your own profile. Read Multiple Firefox Profiles for more help with the profile manager.

Handy Links

How To and Oft-Used

• Release_Management
• Firefox/Channels/Meetings
• ESR FAQ
• Enterprise/Firefox/ExtendedSupport:Proposal
• Release_Management/ESR_Landing_Process

General info on module owners and partners:

• Module owners All Modules
• Mozilla Partners Partner Rolodex - Request permissions to your manager if you can't access this document.

Bugzilla

• Configure the securemail section if you want to see the content of security bugs in your email client. GPG key or SMIME certificate are accepted.
• If you don't mind receiving plenty of emails, you can ask to the bugzilla admin to receive notifications for Firefox uplift requests

Reports

• release tracking report (builds bugzilla queries for uplifts)

Queries

In your bugzilla preferences, under Saved Searches, you can add some of the following to your footer for quick access:

• approval-beta?
• As an exercise, also create the query approval-release? (hint: edit the approval-beta? such, update the value and save it with the new name)
• tracking_firefoxXY? (adjust for current beta version as needed)
• Firefox XY tracked bugs (Make sure to query for the resolved bugs as well as open ones)
• ESR tracked list
• New regressions - Note that fix-optional should be removed from this query
• Carryover regressions - Note that fix-optional should be removed from this query
• relnote-firefox?
• Also create query for approval-esrXY

Tools

Repos to check out if you are going to develop

• Bugzilla nag tool
• ship-it
• Nucleus
• Bedrock Mozilla website
• mozregression

Helpful webextensions

• Crash Stop provides crash data in Bugzilla
• Gecko Code Coverage provides code coverage info in Bugzilla, crash-stats, dxr, hg.m.o, ...

Community Contributors

Some of the above access & permissions will either not be accessible to community contributors or it might take a bit longer to achieve depending on the level & needs of the contributions being made.

Currently when Early Feedback Community Release Managers are onboarded we're basing it on these blog posts (one was based on the other). The short version is that we're looking for people who are interested in understanding how Release Management in a major Open Source project works and our hope is that they learn while also helping us maintain a higher level of quality and visibility into release-affecting issues than a small team of employees can manage.

How that can play out is in several ways. First, any new community member who wants to work with RelMan should have a very informal conversation with a current staff member to discuss their experience, interests, and then ultimately to come up with a good time for a regular meeting that can onboard them (if they're still interested) over a period of weeks & months.

Depending on the volunteer's time availability, usually 1 or 2 hour-long triage sessions a week are feasible. Ideally these will at least sometimes include other members of the team so that the new contributor is getting to know the rest of the members. Eventually the contributor should also start getting invited to (and attending when possible) our 30 min weekly team meeting.

Links to get started

• Nightly Triage
• All Queries
• Landing Plan
• Article on our release process in Dr. Dobbs (mostly still true)

Fun Tips & Tricks

Subscribe to fun stuff

• See Email groups "Fun Stuff" above to self-subscribe

Overview Summary of Role

• It would help to imagine the Relman role as a manager of three stages. Imagine a kanban with three columns where each stage is a column. Each stage is a cycle of the release process. (Nightly, Beta, Release). A Relman is assigned a release (#). You see that release (#) through each column(stage). Each column has different dates, similar processes(some automated some manual), different dates, and different level of critical tasks. To ensure nothing is forgotten, we follow checklists which change depending on which stage you are in as well as which part of the stage you are in (beginning/end).
• Must Read: Release Process