[tor-commits] [tor/master] Update releasing-tor to reflect current versions and tooling

Fri May 26 14:22:58 UTC 2017

commit 1405bdebb0a1d6c92c95b7ef1577856eec776dea
Author: Nick Mathewson <nickm at torproject.org>
Date:   Fri May 26 10:01:04 2017 -0400

    Update releasing-tor to reflect current versions and tooling
    
    (Note that a lot of the removed guidance is stuff that the tools
    will do automatically.)
---
 doc/HACKING/ReleasingTor.md | 70 +++++++++++++++++++--------------------------
 1 file changed, 30 insertions(+), 40 deletions(-)

diff --git a/doc/HACKING/ReleasingTor.md b/doc/HACKING/ReleasingTor.md
index 809cd03..4ece4d7 100644
--- a/doc/HACKING/ReleasingTor.md
+++ b/doc/HACKING/ReleasingTor.md
@@ -26,8 +26,6 @@ new Tor release:
 
    What about Coverity Scan?
 
-   Is make check-spaces happy?
-
    Does 'make distcheck' complain?
 
    How about 'make test-stem' and 'make test-network'?
@@ -44,21 +42,16 @@ new Tor release:
    of them and reordering to focus on what users and funders would find
    interesting and understandable.
 
-   1. Make sure that everything that wants a bug number has one.
-      Make sure that everything which is a bugfix says what version
-      it was a bugfix on.
-
-   2. Concatenate them.
-
-   3. Sort them by section. Within each section, sort by "version it's
-      a bugfix on", else by numerical ticket order.
-
-   4. Clean them up:
+   To do this, first run `./scripts/maint/lintChanges.py changes/*` and
+   fix as many warnings as you can.  Then run `./scripts/maint/sortChanges.py
+   changes/* > changelog.in` to combine headings and sort the entries.
+   After that, it's time to hand-edit and fix the issues that lintChanges
+   can't find:
 
-      Standard idioms:
-      `Fixes bug 9999; bugfix on 0.3.3.3-alpha.`
+   1. Within each section, sort by "version it's a bugfix on", else by
+      numerical ticket order.
 
-      One space after a period.
+   2. Clean them up:
 
       Make stuff very terse
 
@@ -86,16 +79,15 @@ new Tor release:
       maint-0.2.1), be sure to make the stanzas identical (so people can
       distinguish if these are the same change).
 
-   5. Merge them in.
+   3. Clean everything one last time.
 
-   6. Clean everything one last time.
+   4. Run `./scripts/maint/format_changelog.py --inplace` to make it prettier
 
-   7. Run `./scripts/maint/format_changelog.py` to make it prettier.
 
 2. Compose a short release blurb to highlight the user-facing
    changes. Insert said release blurb into the ChangeLog stanza. If it's
    a stable release, add it to the ReleaseNotes file too. If we're adding
-   to a release-0.2.x branch, manually commit the changelogs to the later
+   to a release-* branch, manually commit the changelogs to the later
    git branches too.
 
 3. If there are changes that require or suggest operator intervention
@@ -116,38 +108,40 @@ new Tor release:
 
 === III. Making the source release.
 
-1. In `maint-0.2.x`, bump the version number in `configure.ac` and run
+1. In `maint-0.?.x`, bump the version number in `configure.ac` and run
    `scripts/maint/updateVersions.pl` to update version numbers in other
-   places, and commit.  Then merge `maint-0.2.x` into `release-0.2.x`.
+   places, and commit.  Then merge `maint-0.?.x` into `release-0.?.x`.
 
    (NOTE: To bump the version number, edit `configure.ac`, and then run
    either `make`, or `perl scripts/maint/updateVersions.pl`, depending on
    your version.)
 
-2. Make distcheck, put the tarball up somewhere, and tell `#tor` about
-   it. Wait a while to see if anybody has problems building it. Try to
-   get Sebastian or somebody to try building it on Windows.
+2. Make distcheck, put the tarball up in somewhere (how about your
+   homedir on your homedir on people.torproject.org?) , and tell `#tor`
+   about it. Wait a while to see if anybody has problems building it.
+   (Though jenkins is usually pretty good about catching these things.)
 
 === IV. Commit, upload, announce
 
 1. Sign the tarball, then sign and push the git tag:
 
         gpg -ba <the_tarball>
-        git tag -u <keyid> tor-0.2.x.y-status
-        git push origin tag tor-0.2.x.y-status
+        git tag -u <keyid> tor-0.3.x.y-status
+        git push origin tag tor-0.3.x.y-status
 
 2. scp the tarball and its sig to the dist website, i.e.
    `/srv/dist-master.torproject.org/htdocs/` on dist-master. When you want
    it to go live, you run "static-update-component dist.torproject.org"
    on dist-master.
 
-   Edit `include/versions.wmi` and `Makefile` to note the new version.
+   In the webwml.git repository, `include/versions.wmi` and `Makefile`
+   to note the new version.
 
    (NOTE: Due to #17805, there can only be one stable version listed at
    once.  Nonetheless, do not call your version "alpha" if it is stable,
    or people will get confused.)
 
-3. Email the packagers (cc'ing tor-assistants) that a new tarball is up.
+3. Email the packagers (cc'ing tor-team) that a new tarball is up.
    The current list of packagers is:
 
        - {weasel,gk,mikeperry} at torproject dot org
@@ -156,11 +150,7 @@ new Tor release:
        - {lfleischer} at archlinux dot org
        - {Nathan} at freitas dot net
        - {mike} at tig dot as
-       - {tails-rm} at boum dot org (for pre-release announcments)
-
-
-       - {tails-dev} at boum dot org (for at-release announcements)
-
+       - {tails-rm} at boum dot org
 
 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
@@ -176,17 +166,17 @@ new Tor release:
    blog-formatted version of the changelog with the -B option to
    format-changelog.
 
-   When you post, include an estimate of when the next TorBrowser releases
-   will come out that include this Tor release.
+   When you post, include an estimate of when the next TorBrowser
+   releases will come out that include this Tor release.  This will
+   usually track https://wiki.mozilla.org/RapidRelease/Calendar , but it
+   can vary.
 
 
 === 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.  Do a similar `merge -s theirs`
-    merge to get the change (and only that change) into release.  (Some
-    of the build scripts require that maint merge cleanly into release.)
+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.
 
 2. Forward-port the ChangeLog (and ReleaseNotes if appropriate).
 

