Onboarding process in the Release Management team
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.
- 1 Account Permissions
- 2 Communication Channels
- 3 Software
- 4 Handy Links
- 5 Tools
- 6 Community Contributors
- 7 Fun Tips & Tricks
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.
- 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 is available behind our VPN, note that you will need to use Mozilla DNS servers to resolve the url.
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 to have 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 Johan Lorenzo) to send you an invite to manage Firefox snaps. The Snap uploading process was defined in bug 1467261.
Request admin access to https://nucleus.mozilla.org by filing two bugs.
Google Play Console
Ask your manager to add you.
- https://crash-stats.mozilla.com/ should be accessible for general use. If you require enhanced permissions, 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. As of October 2019 work is ongoing on a revised version of this dashboard that will be used for Desktop. We will continue to use Mission Control v1 for Fennec crash reporting.
Trello is used to track the shipping of Firefox features in the Firefox Trello Board. Ask Erin Lancaster (elan on IRC) 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 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 lists
- email@example.com: General discussions for the whole team
- firstname.lastname@example.org: Discussions about releases, schedule…
- email@example.com: Discussions about code coverage, machine learning/Artificial Intelligence, static analysis…
Other useful lists You'll need to manually subscribe to:
- release-automation-notifications (Contributors need aninvite)
- security-group Check out the policy for getting added to the security-group list.
IRC is our traditionnal chatting tool, we run our own server (irc.mozilla.org) with a thousand specialized chat rooms. Some people prefer Slack, other IRC so we have chatroom in both.
airmozilla- back channel for public broadcasts
developers- monitor check-ins and speak with devs
fx-team- good place to speak with desktop team
mobile- good place to speak with mobile devs
moco[access_key is here ]
planning- back channel for product coordination meeting, good place to speak with broader product team
pm- Project management
release-drivers- release related discussions
releng- releng team channel
releaseduty- releng team's releaseduty channel
release-mgmt- our team channel, needs a password, ask relman team.
security(ask for channel key) - the security team's channel
qa- QE team channel
www- for speaking with the mozilla.org team in case a push breaks or otherwise doesn't work
Many folks uses IRC Cloud as Mozilla as an instance (request an account in Service Now), others run a BNC (an IRC bouncer) (e.g. znc) and/or
irssi under screen to get continuous view of traffic.
See below for a local pastebin install, so you don't paste huge amounts in channel.
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
As a release manager, you will need to attend recurrent meetings, here is the list:
- 1st Channel meeting
- Feature Deep Dive meeting
- Cross Functionnal meeting
- 2nd Channel meeting
- Our Team 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
- https://public.etherpad-mozilla.org/p/firefox43-worry-list Worry list specific to each release (change the version in the url as needed)
it creates a new page from stdin, and outputs the url to stdout an argument will be interpretted as the syntax highlighting format to use sample usage: hg diff | pastebin python | pbcopy (last part mac specific) set & export PASTEBIN_NAME if you don't want to post as anonymous.
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).
- Please download & install Firefox nightly, beta and release
- Create new profiles for each version + your own profile. Read Multiple Firefox Profiles for more help with the profile manager.
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
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
- Crash Stop provides crash data in Bugzilla
- Gecko Code Coverage provides code coverage info in Bugzilla, crash-stats, dxr, hg.m.o, ...
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
- Aurora/DevEdition Landing Process
- Article on our release process in Dr. Dobbs (mostly still true)
Fun Tips & Tricks
Subcribe to fun stuff
- Request here https://bugzilla.mozilla.org/show_bug.cgi?id=391268