From e82f36bccc5b3bc47c3a33d357092cf21b967a5e Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Thu, 13 Aug 2020 09:56:27 -0400 Subject: Update ReleasingTor.md to current practice --- doc/HACKING/ReleasingTor.md | 79 +++++++++++++++++---------------------------- 1 file changed, 30 insertions(+), 49 deletions(-) (limited to 'doc') diff --git a/doc/HACKING/ReleasingTor.md b/doc/HACKING/ReleasingTor.md index d9b8d9d823..6513583ec5 100644 --- a/doc/HACKING/ReleasingTor.md +++ b/doc/HACKING/ReleasingTor.md @@ -9,8 +9,20 @@ new Tor release: version number in their approved versions list. Give them a few days to do this if you can. -2. If this is going to be an important security release, give the packagers - some advance warning: See this list of packagers in IV.3 below. +2. If this is going to be an important security release, give these packagers + some advance warning: + + - {weasel,sysrqb,mikeperry} at torproject dot org + - {blueness} at gentoo dot org + - {paul} at invizbox dot io + - {vincent} at invizbox dot com + - {lfleischer} at archlinux dot org + - {Nathan} at freitas dot net + - {mike} at tig dot as + - {tails-rm} at boum dot org + - {simon} at sdeziel.info + - {yuri} at freebsd.org + - {mh+tor} at scrit.ch 3. Given the release date for Tor, ask the TB team about the likely release date of a TB that contains it. See note below in "commit, upload, @@ -36,19 +48,6 @@ new Tor release: * On OSS-Fuzz -3. Run checks that aren't covered above, including: - - * `clang scan-build`. (See the script in ./scripts/test/scan_build.sh) - - * `make test-network` and make `test-network-all` (with - --enable-fragile-hardening) - - * Running Tor yourself and making sure that it actually works for you. - - * Running Tor under valgrind. (Our 'fragile hardening' doesn't cover - libevent and openssl, so using valgrind will sometimes find extra - memory leaks.) - ## II. Write a changelog 1a. (Alpha release variant) @@ -57,10 +56,12 @@ new Tor release: of them and reordering to focus on what users and funders would find interesting and understandable. - To do this, run `./scripts/maint/sortChanges.py changes/* > changelog.inx` - to combine headings and sort the entries. Copy the changelog.in file - into the ChangeLog. Run 'format_changelog.py' (see below) to clean - up the line breaks. + To do this, run `./scripts/maint/sortChanges.py changes/* > changelog.in` + to combine headings and sort the entries. Copy the changelog.in file into + the ChangeLog. Run `format_changelog.py --inplace` (see below) to clean up + the line breaks. + + Remove the `changes/*` files that you just merged into the ChangeLog. After that, it's time to hand-edit and fix the issues that lintChanges can't find: @@ -140,10 +141,11 @@ new Tor release: places, and commit. Then merge `maint-0.?.x` into `release-0.?.x`. When you merge the maint branch forward to the next maint branch, or into - master, merge it with "-s ours" to avoid a needless version bump. + master, merge it with "-s ours" to avoid conflict with the version + bump. 2. Make distcheck, put the tarball up in somewhere (how about your - homedir on your homedir on people.torproject.org?) , and tell `#tor-dev` + homedir on people.torproject.org?) , and tell `#tor-dev` about it. If you want, wait until at least one person has built it @@ -151,7 +153,6 @@ new Tor release: CI has successfully caught these kinds of errors for the last several years.) - 3. Make sure that the new version is recommended in the latest consensus. (Otherwise, users will get confused when it complains to them about its status.) @@ -179,7 +180,6 @@ $ git push origin tag tor-0.4.x.y- `/srv/dist-master.torproject.org/htdocs/` on dist-master. Run "static-update-component dist.torproject.org" on dist-master. - In the webwml.git repository, `include/versions.wmi` and `Makefile`. In the project/web/tpo.git repository, update `databags/versions.ini` to note the new version. Push these changes to master. @@ -190,20 +190,8 @@ $ git push origin tag tor-0.4.x.y- (NOTE: It will take a while for the website update scripts to update the website.) -3. Email the packagers (cc'ing tor-team) that a new tarball is up. - The current list of packagers is: - - - {weasel,sysrqb,mikeperry} at torproject dot org - - {blueness} at gentoo dot org - - {paul} at invizbox dot io - - {vincent} at invizbox dot com - - {lfleischer} at archlinux dot org - - {Nathan} at freitas dot net - - {mike} at tig dot as - - {tails-rm} at boum dot org - - {simon} at sdeziel.info - - {yuri} at freebsd.org - - {mh+tor} at scrit.ch +3. Email the tor-packagers@lists.torproject.org mailing list to tell them + about the new release. Also, email tor-packagers@lists.torproject.org. @@ -211,22 +199,15 @@ $ git push origin tag tor-0.4.x.y- Include a link to the changelog. -4. Add the version number to Trac. To do this, go to Trac, log in, - select "Admin" near the top of the screen, then select "Versions" from - the menu on the left. At the right, there will be an "Add version" - box. By convention, we enter the version in the form "Tor: - 0.4.0.1-alpha" (or whatever the version is), and we select the date as - the date in the ChangeLog. - -5. Wait for the download page to be updated. (If you don't do this before you +4. Wait for the download page to be updated. (If you don't do this before you announce, people will be confused.) -6. Mail the release blurb and ChangeLog to tor-talk (development release) or +5. Mail the release blurb and ChangeLog to tor-talk (development release) or tor-announce (stable). Post the changelog on the blog as well. You can generate a blog-formatted version of the changelog with - `./scripts/maint/format_changelog.py --B` + `./scripts/maint/format_changelog.py -B` When you post, include an estimate of when the next TorBrowser releases will come out that include this Tor release. This will @@ -239,8 +220,8 @@ $ git push origin tag tor-0.4.x.y- ## V. Aftermath and cleanup 1. If it's a stable release, bump the version number in the - `maint-x.y.z` branch to "newversion-dev", and do a `merge -s ours` - merge to avoid taking that change into master. + `maint-x.y.z` branch to "newversion-dev", and do a `merge -s ours` + merge to avoid taking that change into master. 2. If there is a new `maint-x.y.z` branch, create a Travis CI cron job that builds the release every week. (It's ok to skip the weekly build if the -- cgit v1.2.3-54-g00ecf