@@ -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
-
Rework release-technician-checklist.txt to be more accessible, while still being focused on someone familiar with the process: 1. Have the "Quick cheat-sheet" at the top, with the very first suggestion to run `release help`. 2. Include a slightly more verbose description of the checklist after that. 3. Add an overview of the process for people not familiar with it, as well as a "bootstrapping" process. Get rid of most of the runes now present in `scripts/release`; retain the runes not present there. Signed-off-by: George Dunlap <george.dunlap@citrix.com> --- CC: Ian Jackson <ian.jackson@citrix.com> --- docs/process/release-technician-checklist.txt | 261 ++++++++++-------- 1 file changed, 144 insertions(+), 117 deletions(-)