diff --git a/docs/process/release-technician-checklist.txt b/docs/process/release-technician-checklist.txt
index 5dd85dbc40..5dd0646e65 100644
--- a/docs/process/release-technician-checklist.txt
+++ b/docs/process/release-technician-checklist.txt
@@ -1,30 +1,155 @@
+# Quick cheat-sheet
 
-s=master
-#b=unstable
-v=$v-rc1
+From a different tree, run `scripts/release help` to get a quick
+overview.  For a full description of the process, start with the
+"Details about the process" section below.
 
-OR
+Basic requirements for signing:
 
-x=4.1
-m=1
-rc=-rc2
+* Access to the private Xen signing key
+(23E3222C145F4475FA8060A783FE14C957E82BD9)
 
-r=$x.$m
-s=$x-testing
-#b=$x-testing
-v=$r$rc
+* A repo whose 'origin' will push to xenbits
 
-t=$r$rc
-OR
-t=RELEASE-$r
+Requirements for pushing to the website:
 
+* A local copy of the cvs repo (see below)
 
-# FIRSTLY
-#  - check (for point releases, but not RCs) all XSAs have been applied (Lars)
-#
-* check, even for point releases
-*  http://logs.test-lab.xenproject.org/osstest/results/all-branch-statuses.txt
+* ssh access to mail.xenproject.org
 
+The basic overview:
+
+* Do basic release checks (see the next section).
+
+* Create a signed tag based based on the release manager's specifications
+   $path/scripts/release tag v=4.13.0-rc1 c=<commit-hash>
+
+* Make, sign, and build-test a tarball
+   $path/scripts/release make-tarball v=4.13.0-rc1
+
+* Push the signed tag to the tree:
+   $path/scripts/release push-tag v=4.13.0-rc1
+
+* Push the tarball and signature to the website:
+   $path/scripts release tarball-cvs-checkin-and-post v=4.13.0-rc1
+
+RC vs RELEASE is automatically detected by the script; to tag an RC
+use `v=4.13.0-rc1`; to tag the corresponding release, run the same
+sequence of commands with `v=4.13.0`.
+
+Each command will also prompt you with the command to run next.
+
+# Detailed checklist
+
+* Consider bumping sonames of shared libraries
+
+* All XSAs have been applied
+
+* Tags (not commit hashes) for xenproject-related trees in Config.mk
+
+`grep Config.mk _REVISION` should turn up only tags for QEMU_UPSTREAM,
+MINIOS, and QEMU_TRADITIONAL.  See below for more details.
+
+* The version has been appropriately updated in various places
+  - xen.git/README:
+     During development: "4.12-unstable"
+     For RCs: "4.12-rc"
+     For release: "4.12"
+
+  - xen.git/SUPPORT.md:Xen-Version
+     During development: "4.12-unstable"
+     For RCs: "4.12-rc"
+     For release: "4.12.0"
+     
+  - xen.git/xen/Makefile:XEN_EXTRAVERSION
+     During development: "-unstable$(XEN_VENDORVERSION)"
+     For RCs: ".0-rc$(XEN_VENDORVERSION)"
+     For release: ".0$(XEN_VENDORVERSION)
+
+* Debug has been disabled
+  - tools/Rules.mk:debug ?= n
+  - xen/Kconfig.debug:config DEBUG should default to `n`
+
+* The branch or changeset in question has passed the pushgate
+
+See http://logs.test-lab.xenproject.org/osstest/results/all-branch-statuses.txt
+
+# Details about the process
+
+Two general outputs of this process:
+
+* A signed commit in the upstream repository
+
+* A tarball made from this commit, signed, placed on downloads.xenproject.org
+
+## Tag structure
+
+Tags for RCs follow the following form:
+  4.13.0-rc1
+  4.8.4-rc5
+
+Tags for releases follow the following form:
+  RELEASE-4.13.0
+  RELEASE-4.8.4
+
+## Requisite tags in other trees
+
+The Xen build pulls in a number of other git trees.  Some of these,
+like seabios and ovmf, are outside our project; but qemu,
+qemu-traditional, and minios are inside.  An exact revision is
+specified, such that the pushgate can test specific versions of Xen
+with specific versions of these other projects.
+
+During development, these revisions are normally a commit hash; but on
+release (even an RC), we want these revisions to be a tag signed with
+the XenProject private key.
+
+So before a release, Config.mk must be checked to see if there are
+hash-like values in any of the following values:
+`QEMU_UPSTREAM_REVISION`, `MINIOS_UPSTREAM_REVISION`, OR
+`QEMU_TRADITIONAL_REVISION`.
+
+If so, the following sequence of events must first happen:
+ * Those trees must have signed tags made (see below for a template)
+ * A commit must be made in xen.git pointing to those tags
+ * That commit must pass the push gate
+
+## cvs as a CMS
+
+`downloads.xenproject.org` points to `mail.xenproject.org`.  In order
+to have traceability, and all the things you want from this sort of
+system, you want a version control system. Git is notoriously bad for
+large files, so CVS is used.
+
+On `mail.xenproject.org`, there is a master repository at
+`/home/downloads-cvs/cvs-repos/xen.org`.  This repo is checked out at
+`/data/downloads.xenproject.org/xen.org`.  The specific directory used
+for release tarballs is `oss-xen/release/$v/` (which will show up at
+`http://downloads.xenproject.org/release/xen/$v/`).
+
+So the general process for publishing a xen tarball and signature is:
+ 
+* Add the tarball and signature to a locally-checked-out copy of the cvs tree
+
+    cvs add -kb oss-xen/release/$v/
+    cvs add -kb oss-xen/release/$v/xen-$v.tar.gz
+    cvs add -kb oss-xen/release/$v/xen-$v.tar.gz.sig
+
+* "Check in" the files (which pushes them to the central repo)
+
+    cvs ci -m $v
+
+* Update the CVS repo in the website copy of the repo.
+
+(From `mail.xenproject.org:/data/downloads.xenproject.org/xen.org`)
+
+    cvs -q up -d
+
+You can get your own local copy of this using the following rune:
+
+    cvs -d mail.xenproject.org:/home/downloads-cvs/cvs-repos co xen.org
+
+# Making tags for subprojects
 
 # QEMU
 
@@ -46,101 +171,3 @@ t=RELEASE-$r
   git tag -u 'xen tree' -s -m "Xen $r$rc" qemu-xen-$v 
   git push osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git qemu-xen-$v
 
-* consider bumping sonames of shlibs
-
-* change xen-unstable README (should say "Xen 4.5" in releases and on stable branches, "Xen 4.5-unstable" on unstable)
-* change xen-unstable Config.mk (QEMU_UPSTREAM_REVISION, QEMU_TRADITIONAL_REVISION, MINIOS_UPSTREAM_REVISION)
-* change SUPPORT.md heading version number; -unstable or -rc tag
-*     (empty in stable branches after .0 release).
-*     insert correct version number in release-notes link
-* change xen-unstable xen/Makefile XEN_EXTRAVERSION
-# if main version number has changed (eg 4.7 -> 4.8) rerun ./autogen.sh
-* rerun ./autogen.sh to update version number in configure
-#    - XEN_EXTRAVERSION should be `.0-rc$(XEN_VENDORVERSION)'
-#
-#    - turn off debug on stable branches, if not already done
-#           - tools/Rules.mk
-#                 debug ?= n
-#           - xen/Kconfig.debug
-#                 config DEBUG
-#                     default n
-
-* tag xen-unstable
-
-# In xen.git
-  git-fetch origin
-  git-checkout staging-$x
-  git-pull
-  git-show # should show commit updating version to right version
-  git-tag -u 'xen tree' -s -m "Xen $r$rc" $t
-  git-push origin $t
-  git-push origin staging-$x
-##  hg tag <tag_name> ; hg sign -k "Xen tree" <tag_name>
-
-
-
-HANDLING TAG GENERATED BY RELEASE MANAGER
-
-   fetch the tag into my tree
-   make the tarball (RELEASE TARBALL, below)
-   test build (see below)
-   website (see below)
-   merge tag into staging and push to staging
-   maybe force push into master
-   definitely push tag to xenbits
-        git-push origin $t
-
-
-
-
-RELEASE TARBALL
-
-   for 4.5 and later, use tarball target
-       git checkout $t
-       git clean -xdff
-       # export http_proxy=http://localhost:3128/
-       ./configure
-       make src-tarball-release   # must be used for actual releases
-       make src-tarball           # uses git-describe (best for RCs)
-        # ^find some way to add git-cache-proxy to this (done in ~iwj/.gitconfig)
-       mkdir /volatile/iwj/website-thing/xen.org/oss-xen/release/$v
-       mv dist/xen-$v.tar.gz /volatile/iwj/website-thing/xen.org/oss-xen/release/$v/.
-
-       # website-thing/xen.org is cvs -d mail.xenproject.org:/home/downloads-cvs/cvs-repos co xen.org
-	cd /volatile/iwj/website-thing/xen.org
-
-# test build
-                cd /volatile/iwj/d
-                mkdir build
-                cd build
-                tar zxf /volatile/iwj/website-thing/xen.org/oss-xen/release/$v/xen-$v.tar.gz
-#                rsync -a --delete xen-$v build/
-                cd xen-$v
-                export http_proxy=http://localhost:3128/
-                (./configure && make -j4 KERNELS='' && echo ok.) 2>&1 | tee ../log.$v       # post 4.2
-
-# [[ test build amd64 ]]
-
-	cvs add -kb oss-xen/release/$v/
-
-        cd oss-xen/release/$v
-        gpg --digest-algo=SHA256 --detach-sign -u 'xen tree' xen-$v.tar.gz
-	cvs add -kb xen-$v.tar.gz
-        cvs add -kb xen-$v.tar.gz.sig
-        cd ../../..
-
-	cvs ci -m $v
-
-        ssh downloads-cvs@mail.xenproject.org
-	cd /data/downloads.xenproject.org/xen.org
-	cvs -q up -d
-	# should show something like
-	#   U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.gz
-	#   U oss-xen/release/4.8.0-rc2/xen-4.8.0-rc2.tar.gz.sig
-
-
-update xenbits front page to change references to old stable branch
- into references to new stable branch
-
-Edit website
-
