In the beginning of your shift

  • Check the Mozilla release calendars:
  • Send the release schedule to tails-dev@boum.org and tails-l10n@boum.org. Ask the core team and contributors for availability at the dates designated for testing the RC and final image.
  • Update calendar accordingly.
  • Update the due date on roadmap accordingly.
  • Ask to be added to the rsync_tails group on rsync.lizard, if needed.
  • Make sure you have access to the various systems used to do the release.
  • Check when the SSL certificate for https://tails.boum.org/ expires. If that's before, or soon after, the scheduled date for the release after the one your shift is about, then:
    • Get in touch with root@boum.org to know about their plans.
    • Create a ticket for the release your shift is about, so that we update the CA bundle that's used by Tails Upgrader and the security check.
  • 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.

Around two weeks before the freeze

  • Have a look at recent changes in Torbutton, and make sure they are compatible with our configuration.
  • If needed, update the list of Tor authorities in the test suite configuration (TOR_AUTHORITIES).
  • Check that the list of backends we ship in /usr/lib/cups/backend are all listed in the (patched) /etc/apparmor.d/usr.sbin.cups:
    • backends shipped in cups-daemon should have ixr
    • other backends should have Cx -> third_party If anything doesn't match this, let intrigeri know.

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 tails-dev@ when sending QA requests to tor-qa@lists.torproject.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.


The RM is still the fallback for reviewing'n'merging stuff relatively promptly. If a ticket is flagged "Ready for QA", but the RM cannot take care of the review'n'merge, it's the RM's responsibility to ask for help. These tickets can be tracked using:

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 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 fine.


On Redmine: