1 [[!meta title="Release Manager"]]
5 ## In the beginning of your shift
7 - Send the release schedule on tails-dev when beginning their shift.
8 - Ask to be added to the `rsync_tails` group on `rsync.lizard`,
10 - Make sure you have access to the various systems used to do
13 ## Around two weeks before the freeze
15 - Have a look at recent changes in the
16 [Torbrowser](https://gitweb.torproject.org/torbrowser.git)'s prefs
17 (e.g. `git log -p build-scripts/config/*.js`) and import the
18 relevant ones to our Iceweasel configuration, following the normal
19 review'n'merge process. **Note**: for TBB 3.0 and beyond, the
20 `tor-browser.git` patch that adds
21 `browser/app/profile/000-tor-browser.js` will be the only place
22 for these prefs, instead of config files in `torbrowser.git`
23 (notice the additional *-*).
24 - In particular, make sure the `general.*` and
25 `browser.startup.homepage_override.*` prefs are in sync', in our
26 `/etc/iceweasel/pref/iceweasel.js`, with TBB's `pound_tor.js`.
27 - Have a look at recent changes
28 in [Torbutton](https://gitweb.torproject.org/torbutton.git), and
29 do whatever is needed to get the fixes we need in the release.
30 - Have kytv upgrade I2P if needed. See [[contribute/design/I2P]].
32 ## Make the release happen
34 No kidding. See [[contribute/release_process]].
38 The release manager shifts could be done by a team. They start right after the
39 publication of the previous release to the publication and announcement of the
40 release they are taking care of, which should be 6 weeks long if everything goes