blob: 4e38fae4f7657fb8c730700e578d860dd03d50bb (plain
[[!meta title="Release Manager"]]
## In the beginning of your shift
- Check the Mozilla release calendars:
* [Google calendar](https://www.google.com/calendar/embed?src=mozilla.com_2d37383433353432352d3939%40resource.calendar.google.com)
* [Release schedule](https://wiki.mozilla.org/RapidRelease/Calendar)
- Send the release schedule to <firstname.lastname@example.org> and
- Ask the core team and contributors for availability at the
designated dates for testing the RC and final image.
- Ask `tails@` for a _Trusted Reproducer_ who will reproduce the
ISOs and IUKs for the RC and final release within 72 hours after
the RM has unplugged their smartcard. When accepting the offer,
the Trusted Reproducer must read the [["Preparation" section of
- Update [[contribute/calendar]] accordingly.
- Update the due date on [[!tails_roadmap]] accordingly.
- Ask to be added to the `rsync_tails` group on `rsync.lizard`,
- Make sure you have access to the various systems used to do
- Check when our OpenPGP signing key expires.
If that's before, or soon after, the scheduled date for the release
_after_ the one your shift is about, then shout.
## Two weeks after the beginning of your shift
- Ensure you have found a _Trusted Reproducer_ and write who this is
in the [[contribute/calendar]].
## The Friday before the release date
We need to coordinate our Tails release with the Tor Browser
developers to make sure that the Tor Browser we plan to include in our
release is ready in time for when we build the release image. The
Friday prior to the release seems like a good candidate, since it's
around this time they usually release tarballs for testing, and it
will still give some time for us to improvise according to their
"delayed" schedule and arrange a contingency plan (e.g. possibly
delaying our release a day or two). Asking for a status report a day
or two earlier than Friday *in addition* won't hurt, too.
Note: Georg Koppen, a Tor Browser developer, has promised to try to Cc
email@example.com when sending QA requests to firstname.lastname@example.org
which should make this easier. We should also be notified of any last
last-minute rebuilds that we otherwise probably would miss out on.
[[Upgrading the Tor Browser|contribute/release_process/tor-browser]]
page for details.
## At least for the first release of the year
Have a look at scenarios or features added or modified since last time
this check was done, and check if the ones that depend on the
documentation have the `@doc` tag.
## Make the release happen
No kidding. See [[contribute/release_process]].
The release manager shifts could be done by a team. They start right after the
publication of the previous release to the publication and announcement of the
release they are taking care of, which should be 6 weeks long if everything goes