Duties

The Tails Release Managers are primarily responsible for:

  • publishing new Tails versions in a timely fashion, according to the schedule submitted by the Foundations Team;

  • reaching a consensus regarding documenting, delaying, or releasing, when emergency releases might be warranted (usually prompted by unplanned Tor Browser releases for security issues that require urgent care);

  • making sure automatic and manual testers are covered during each release process;

  • being in the loop when major changes land in release branches, so that they can propose extra manual tests if those changes feel risky (e.g. changes in the upgrader code).

To ensure releasing is achievable in a timely manner, historically, they have also been responsible for:

  • making sure the various Git branches get successful builds and test suite runs in Jenkins, filing issues for the Foundations Team as needed.

This responsibility might get shifted to the Foundations Team in the near future though.

Also historically, the Release Manager for a given Tails release deals with integrating the target Tor Browser version, even if that's one of the Foundations Team's duties.

Shift

In the beginning of your shift

  • Check the Mozilla release calendars:
  • Reply to the email sent to tails-dev@boum.org and tails-l10n@boum.org by the RM for the previous release, to provide any information they could not, such as:
    • Code freeze date
    • If this will be a major release: the release schedule for its RC.
  • Ask tails@boum.org and tails-foundations@boum.org for a Trusted Reproducer who will reproduce the ISO and USB images 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 the instructions. If needed, the request can be extended to tails-manual-testers@boum.org.
  • Update calendar accordingly.
  • Check if the due date of the corresponding GitLab milestone is correct. If it is not, create a merge request against tails/gitlab-config to fix it.
  • Make sure you have access to the various systems used to do the release:
    • being subscribed to the tails-rm@boum.org mailing list
    • having your OpenPGP signing subkey hardware and passphrase handy
    • commit access to the official Git repository
    • upload access to our custom APT repository
    • having your GnuPG key in the list of uploaders for our custom APT repository
    • https://jenkins.tails.boum.org/
    • SSH access to rsync.lizard and being a sudoer and in the rsync_tails group there
    • SSH access to bittorrent.lizard and being in the debian-transmission group there
    • SSH access to reprepro-time-based-snapshots@apt.lizard
    • SSH access to misc.lizard
    • look for rsync|ssh in custom, time-based snapshots and this very document
    • access to the RM team's Git repository: install the git-remote-gcrypt package, git clone gcrypt::git@gitlab.tails.boum.org:tails/rm, follow instructions in the README
    • follow the instructions in keyringer/README in the RM team's Git repository then make sure you can keyringer tails-rm decrypt credentials
    • Reporter status on the tails GitLab group
  • 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.
  • The ISO images for every previous beta, RC, and final release based on the version of Debian that will be used for the release you'll be preparing. For example, if you're preparing 4.4, you need the ISO images for 4.0~beta1, 4.0~beta2, 4.0~rc1, 4.0, 4.1, 4.1.1, 4.2, 4.2.2, and 4.3.

Two weeks after the beginning of your shift

  • Ensure you have found a Trusted Reproducer and write who this is in the calendar.
  • Create an issue with the Core Work: Foundations Team label, about upgrading Tor Browser in the release your shift is about.
  • Check if you have enough manual testers registered. If not, ping the usual testers.

The week before the release date

If updating the Changelog is a particularly painful part of the release process for you, then you can do it in smaller chunks, starting ahead of the pre-release Monday.

The first time you run our ./release script to seed the changelog entry from Git commits:

  1. Take note of which commit you're at.
  2. Run it exactly as documented in the release process.

The next times you run our ./release script:

  1. Take note of which commit you're at.
  2. Pass, as a second argument to ./release, the commit you took note of last time you updated the Changelog.

XXX: fix ./release so that there's a way to have it simply run gbp dch --auto, which will avoid the need to take note of commits.

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: the Tor Browser team Cc's tails-dev@boum.org when sending QA requests to tor-qa@lists.torproject.org which makes this easier. We are also often notified of any last last-minute rebuilds, better ask explicitly the Tor Browser team what their plans are.

As soon as the new Tor Browser tarballs are ready, you may import them in a topic branch and trigger CI runs, which will save you some precious time on pre-release Monday. See the Upgrading the 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 release process.