summaryrefslogtreecommitdiffstats
path: root/wiki/src/contribute/working_together/roles/release_manager.mdwn
blob: da13108fc5b821bf2cee37d2cf7397f237e55431 (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
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
[[!meta title="Release Manager"]]

# Tasks

## 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 <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 [[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 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](https://gitweb.torproject.org/torbutton.git), and
  make sure they are compatible with our configuration.
- Have someone ([[!tails_ticket 11276 desc="who?"]]) upgrade I2P if needed.
  See [[contribute/design/I2P]].
- 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 [[!debpkg 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.

## Continuously

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:

* the "Release Manager View";
* the
  [Ready for QA, with no assignee](https://labs.riseup.net/code/projects/tails/issues?query_id=194)
  view.

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

# Tools

On Redmine:

* [Release Manager View](https://labs.riseup.net/code/projects/tails/issues?query_id=130)
* [Ready for QA](https://labs.riseup.net/code/projects/tails/issues?query_id=117)