summaryrefslogtreecommitdiffstats
path: root/wiki/src/contribute/working_together/roles/release_manager.mdwn
blob: 5cdb8243ccb49a39256a70e40ef03f183498b85a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
[[!meta title="Release Manager"]]

# Tasks

## Continuously

Stay on top of email received on the Release Managers mailing list.
This includes for example failure notifications for Jenkins jobs.

## 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/Release_Management/Calendar)
- Send the release schedule to <tails-dev@boum.org> and
  <tails-l10n@boum.org>.
  - 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
    the instructions|test/reproducibility/verification/#preparation]].

- Update [[contribute/calendar]] accordingly.
- Update the due date on [[!tails_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 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.

<div class="note">

Note: Georg Koppen, a Tor Browser developer, has promised to try to Cc
tails-dev@boum.org 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.

</div>

See the
[[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]].

# Shifts

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.