[tor-commits] [tor/master] small tweaks to releasingtor.md

[nickm at torproject.org]

commit 3c9ff0af96835575af942a367726732366977581
Author: Nick Mathewson <nickm at torproject.org>
Date:   Mon Sep 18 14:49:06 2017 -0400

    small tweaks to releasingtor.md
---
 doc/HACKING/ReleasingTor.md | 30 ++++++++++++++++++++++++------
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/doc/HACKING/ReleasingTor.md b/doc/HACKING/ReleasingTor.md
index b206b3149..62029b44f 100644
--- a/doc/HACKING/ReleasingTor.md
+++ b/doc/HACKING/ReleasingTor.md
@@ -8,7 +8,11 @@ new Tor release:
 === 0. Preliminaries
 
 1. Get at least three of weasel/arma/Sebastian/Sina to put the new
-   version number in their approved versions list.
+   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.
 
 
 === I. Make sure it works
@@ -26,19 +30,24 @@ new Tor release:
 
    What about Coverity Scan?
 
+   What about clan scan-build?
+
    Does 'make distcheck' complain?
 
-   How about 'make test-stem' and 'make test-network'?
+   How about 'make test-stem' and 'make test-network' and
+   `make test-network-full`?
 
        - Are all those tests still happy with --enable-expensive-hardening ?
 
    Any memory leaks?
 
 
-=== II. Write a changelog.
+=== II. Write a changelog
 
 
-1. Gather the `changes/*` files into a changelog entry, rewriting many
+1a. (Alpha release variant)
+
+   Gather the `changes/*` files into a changelog entry, rewriting many
    of them and reordering to focus on what users and funders would find
    interesting and understandable.
 
@@ -83,6 +92,15 @@ new Tor release:
 
    4. Run `./scripts/maint/format_changelog.py --inplace` to make it prettier
 
+1b. (old-stable release variant)
+
+   For stable releases that backport things from later, we try to compose
+   their releases, we try to make sure that we keep the changelog entries
+   identical to their original versions, with a 'backport from 0.x.y.z'
+   note added to each section.  So in this case, once you have the items
+   from the changes files copied together, don't use them to build a new
+   changelog: instead, look up the corrected versions that were merged
+   into ChangeLog in the master branch, and use those.
 
 2. Compose a short release blurb to highlight the user-facing
    changes. Insert said release blurb into the ChangeLog stanza. If it's
@@ -109,7 +127,7 @@ new Tor release:
 === III. Making the source release.
 
 1. In `maint-0.?.x`, bump the version number in `configure.ac` and run
-   `scripts/maint/updateVersions.pl` to update version numbers in other
+   `perl scripts/maint/updateVersions.pl` to update version numbers in other
    places, and commit.  Then merge `maint-0.?.x` into `release-0.?.x`.
 
    (NOTE: To bump the version number, edit `configure.ac`, and then run
@@ -165,7 +183,7 @@ new Tor release:
 5. Mail the release blurb and ChangeLog to tor-talk (development release) or
    tor-announce (stable).
 
-   Post the changelog on the the blog as well. You can generate a
+   Post the changelog on the blog as well. You can generate a
    blog-formatted version of the changelog with the -B option to
    format-changelog.