Onboarding process in the Release Management team< Release Management
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.
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.
- Create a Bugzilla account.
- File a bug to request for your bugzilla account to be added to the
mozilla-stable-branch-driversgroups in order to set tracking flags (eg: bug 962151). Make sure you also have the
- 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.
- Ask your manager for the permissions to access the team Google drive folder.
Configure your system to access to the Mozilla VPN in order to get access to internal tools like Ship-It.
Ship It and Balrog
Once you are using the Mozilla VPN, you can access the application and use your LDAP account to log in.
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 (currently specifically Mihai Tabara) to send you an invite to manage Firefox snaps. The Snap uploading process was defined in bug 1467261.
You will need to ask for access to the Samsung Store
Request admin access to https://nucleus.mozilla.org by filing two bugs.
Google Play Console
Ask your manager to add you.
- 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.
- Mission Control is the dashboard we use for crash monitoring and to report at the Channel and Cross Functional Meetings. Mission Control v2 is the newer version.
Trello is used to track the shipping of Firefox features in the Firefox Trello Board. Ask Thomas Elin for access.
Each release has its own column listing the features planned for that specific version. Pro tip: subscribe to a column notification to receive updates given to all the cards in that column.
Our team also has a Trello board but we currently do not use it.
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.
- 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
Ask your manager to give you access to the Release Management PTO calendar where all release managers indicate when they are on PTO.
- 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
- Alot of names will be thrown around the first couple of months, here is a list of common definitions.
- Things to Bookmark
This page describes our release schedule: Firefox Release Calendar. You should add these to your regular Google calender so you can easily see the state of any release.
- 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.
Note that some of these mailing lists need approval from an administrator.
Our team list
- firstname.lastname@example.org: Discussions about releases, schedule…
Other useful lists You'll need to manually subscribe to:
- security-group Check out the policy for getting added to the security-group list.
We hang out in the
The following can also be useful:
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
As a release manager, you will need to attend recurrent meetings, here is the list:
- 1st Channel meeting
- Our Team meeting
- 2nd Channel meeting
Ask your manager and colleagues to invite you to these meetings.
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
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.
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).
How To and Oft-Used
- ESR FAQ
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.
- 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
- release tracking report (builds bugzilla queries for uplifts)
In your bugzilla preferences, under Saved Searches, you can add some of the following to your footer for quick access:
- 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
- Also create query for approval-esrXY
Repos to check out if you are going to develop
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
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