[tor-commits] [tor/master] Update ReleasingTor.md to current practice
nickm at torproject.org
nickm at torproject.org
Thu Aug 13 13:56:33 UTC 2020
commit e82f36bccc5b3bc47c3a33d357092cf21b967a5e
Author: Nick Mathewson <nickm at torproject.org>
Date: Thu Aug 13 09:56:27 2020 -0400
Update ReleasingTor.md to current practice
---
doc/HACKING/ReleasingTor.md | 79 +++++++++++++++++----------------------------
1 file changed, 30 insertions(+), 49 deletions(-)
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-<status>
`/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-<status>
(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 at lists.torproject.org mailing list to tell them
+ about the new release.
Also, email tor-packagers at lists.torproject.org.
@@ -211,22 +199,15 @@ $ git push origin tag tor-0.4.x.y-<status>
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-<status>
## 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
More information about the tor-commits
mailing list