wiki/src/contribute/working_together/roles/release_manager.mdwn

   1 [[!meta title="Release Manager"]]
   2
   3 # Tasks
   4
   5 ## In the beginning of your shift
   6
   7 - Check the Mozilla release calendars:
   8   * [Google calendar](https://www.google.com/calendar/embed?src=mozilla.com_2d37383433353432352d3939%40resource.calendar.google.com)
   9   * [Release schedule](https://wiki.mozilla.org/RapidRelease/Calendar)
  10 - Send the release schedule to <tails-dev@boum.org> and
  11   <tails-l10n@boum.org>.
  12   Ask the core team and contributors for availability at the
  13   dates designated for testing the RC and final image.
  14 - Update [[contribute/calendar]] accordingly.
  15 - Update the due date on [[!tails_roadmap]] accordingly.
  16 - Ask to be added to the `rsync_tails` group on `rsync.lizard`,
  17   if needed.
  18 - Make sure you have access to the various systems used to do
  19   the release.
  20 - Check when the SSL certificate for https://tails.boum.org/ expires.
  21   If that's before, or soon after, the scheduled date for the release
  22   _after_ the one your shift is about, then:
  23   * Get in touch with <root@boum.org> to know about their plans.
  24   * Create a ticket for the release your shift is about, so that we
  25     update the CA bundle that's used by Tails Upgrader and the
  26     security check.
  27 - Check when our OpenPGP signing key expires.
  28   If that's before, or soon after, the scheduled date for the release
  29   _after_ the one your shift is about, then shout.
  30
  31 ## Around two weeks before the freeze
  32
  33 - Have a look at recent changes
  34   in [Torbutton](https://gitweb.torproject.org/torbutton.git), and
  35   do whatever is needed to get the fixes we need in the release.
  36 - Have Kill Your TV upgrade I2P if needed. See [[contribute/design/I2P]].
  37 - If needed, update the list of Tor authorities in the test
  38   suite configuration.
  39
  40 ## Continuously
  41
  42 The RM is still the fallback for reviewing'n'merging stuff relatively
  43 promptly. If a ticket is flagged "Ready for QA", but the RM cannot or
  44 doesn't want to take care of the review'n'merge, it's the RM's
  45 responsibility to ask for help. The "Release Manager View" is probably
  46 the best place to track such tickets.
  47
  48 ## Make the release happen
  49
  50 No kidding. See [[contribute/release_process]].
  51
  52 # Shifts
  53
  54 The release manager shifts could be done by a team. They start right after the
  55 publication of the previous release to the publication and announcement of the
  56 release they are taking care of, which should be 6 weeks long if everything goes
  57 fine.
  58
  59 # Tools
  60
  61 On Redmine:
  62
  63 * [Release Manager View](https://labs.riseup.net/code/projects/tails/issues?query_id=130)
  64 * [Ready for QA](https://labs.riseup.net/code/projects/tails/issues?query_id=117)