--- guides/release-process.mdwn	2014-07-23 15:18:23.604115230 +0100
+++ guides/release-process-new.mdwn	2014-07-23 15:45:28.062484615 +0100
@@ -14,8 +14,8 @@
 Prerequisites for making a release
 ----------------------------------

-> **Note**: Typically, only Baserock maintainers have enough access to complete
-> this process.
+> **Note**: Typically, only Codethink employees have enough access to complete
+> this process. This is to be considered a bug that needs fixing.

 You will need:

@@ -25,12 +25,10 @@
   This VM should have enough space to coordinate the release artifacts.
   In the past, 30G or more was required.  Please refer to other guides
   for setting up such a VM.
-* Available host space for testing `x86` systems.
-* A Wandboard for testing the `armv7lhf` systems.

 If you are doing a GENIVI release, you will also need:

-* A powerful `x86` system capable of emulating ARM's `versatile-pb` platform.
+* An `x86` system capable of emulating ARM's `versatile-pb` platform.

 You will also need access to:

@@ -46,150 +44,67 @@
 Ensure that `morph.conf` on your coordination VM is configured to use your
 internal Trove by setting `trove-id` and `trove-host` as appropriate.

-Pre-release testing
--------------------
-
-All Baserock releases should meet the following standard. Further, Baserock
-should run continuous testing of the 'master' branch of definitions.git to
-identify whenever 'master' is *not* in a releasable state, so that it can be
-fixed.
-
-Systems:
-
-- All combinations of system and architecture which are part of the release
-  should boot successfully and all components should work as expected.
-- These should be built for testing using the Trove and distributed build
-  infrastructure you are using for the release.
-- An example command to build the `x86_64` development system would be:
-
-      morph distbuild --verbose --controller-initiator-address=my-x86_64-controller devel-system-x86_64-generic
-
-- Alternatively you can distbuild all the systems in a cluster using
-  `scripts/distbuild-cluster.py`.  See its `--help` for details.
-
-Definitions:
-
-- All chunk ref fields are pointing at exact commits (SHA1s), *not* named refs
-  (which could be changed any time after the release is built).
-- All chunk commits that are referenced are part of a stable branch in that
-  chunk's repo. (This ensures that the commits will not be garbage collected,
-  as long as the stable branch ref is not force-updated).
-
-Morph:
-
-- Morph's NEWS file should be up to date.
-- Morph's README file should be up to date.
-- The ref for the morph chunk in the tools stratum is up to date.
-
-GENIVI Baseline pre-release testing
------------------------------------
-
-Weston and the Weston ivi-shell should work. See [[the GENIVI page|genivi]] for
-instructions on how to run these.
-
 Deliverables
 ------------

-The weeky release process aims to produce the following:
+See `release.morph` in `definitions.git` for the systems we release.
+In addition to the system images and other files produced by
+`release.morph`, the release requires manually producing or updating
+the following:

-- x86-64 devel raw image and chroot tarball
-- x86-32 devel raw image and chroot tarball
-- armv7lhf-wandboard devel rootfs tarball
-- armv7lhf-wandboard devel kernel uImage
+* Release notes, on `wiki.baserock.org`.
+* Updated symlinks to "current" images and tarballs

 For a GENIVI release, the following artifacts are produced:

-- x86-64 genivi baseline raw image
-- armv7lhf-versatile genivi baseline raw image
-- armv7lhf-versatile genivi baseline kernel zImage
-- GENIVI baseline manifest and license manifest
-- GENIVI release notes
-- An updated version of the `run-built-arm-image.sh` script in
-  baserock:baserock/genivi-initial-setup
-
-Each release should also include:
-
-- Cached artifacts for every built system on the trove.baserock.org cache
-  server.
-- Release notes
-- Updated symlinks to "current" images and tarballs
-- Updates to wiki.baserock.org quick-start and devel-with pages, and other
-  instruction pages
+* GENIVI baseline manifest and license manifest
+* GENIVI release notes
+* An updated version of the `run-built-arm-image.sh` script in
+  `baserock:baserock/genivi-initial-setup`

 Release steps
 -------------

-The release process begins by choosing a commit of definitions to tag as
-a release, and pushing the tag.
+You should do the release in a clean instance of the previous Baserock
+devel system release, preferably on x86 (for speed). This makes it
+possible for others to reproduce the release images you created.
+
+* Create a new branch (`baserock/release/baserock-X.Y`) in
+  `definitions.git`. This is the "release branch", and any changes
+  made during the release will happen there, avoiding the need to
+  freeze master while the release is happening.
+* Get the branch mirrored to your local Trove (push to
+  `git.baserock.org`, promote on your local Trove to get it lorried
+  quickly).
+* Run `scripts/release-build` to produce release artifacts. This
+  script builds all the artifacts needed for the release (using
+  distbuild, so they end up on your local Trove), and creates the
+  release artifacts (all the images and tar archives etc).
+    - See the `scripts/release-build.test.conf` sample configuration
+      file and use that as a basis for your own.
+* Run `scripts/release-upload` to publish release artifacts.
+  This copies build artifacts from your local Trove to
+  `git.baserock.org`, and other files to `download.baserock.org`.
+  After this script has finished successfully, Baserock users can
+  start using the new release.
+    - See the `scripts/release-upload.test.conf` sample configuration
+      file and use that as a basis for your own.
+* Manually create the "current" symlinks pointing at the new release.
+  (FIXME: The upload script should do this automatically, but that
+  code hasn't been written yet.)
+* Tag the HEAD of the release branch with the new release
+  (`baserock-X.Y`). Push the release branch, including tags (`git push
+  --tags`).
+* Prepare or update release notes, wikis, and websites.
+    - Drafting these can start early on, while building and uploading
+      are running.

-We used to tag morph.git with the corresponding Baserock version number, but we
-no longer do this. Currently versions of Morph are identified by the commit
-SHA1.
-
-1. Identify the commit of definitions.git that will be released. This should
-   already be built, tested and known to work on all architectures.
-2. Update `release.morph` to contain the systems that are being released and no
-   others. Check that the configuration is correct.  Ensure that for all systems
-   the system name and deployment name are identical.
-3. Create an annotated release tag in definitions.git:
-
-        git tag -a baserock-XX.XX -m "Baserock release XX.XX"
-
-4. Push your changes to definitions.git on git.baserock.org (again, remember to
-   push the new tag).
-5. Cause the Trove on which you are building the release to update its copy of
-   definitions.git. There is currently no way to do this from the web frontend,
-   but you can log into the Trove and run this [promote.py script].
-6. Write the release notes, and send them as a DRAFT for review to
-    `baserock-dev@baserock.org`. (You can leave this until the release script
-   runs, in fact).
-
-From here, the release process is automated by [scripts/do-release.py] (in
-definitions.git).
-
-The script takes care of:
-
-  - deploying the release images.
-  - fetching and archiving all build artifacts involved in building the
-    release.
-  - uploading the release images to a private directory on the
-    <http://download.baserock.org> server
-  - uploading the release artifacts to a private directory on the
-    <http://trove.baserock.org> Trove.
-  - moving the images and artifacts into publically readable locations once
-    everything has been uploaded
-
-> **Note**: Before running the do-release.py ensure that the `release` directory
-> exists at `/src/release/`.
-
-You should run the script from a clean instance of the previous Baserock devel
-system release, preferably on x86. This makes it easier for others to
-reproduce the release images you created. You should *not* do a release from a
-Baserock system that has local modifications, or that was built from commits
-that are not part of stable branches in git.baserock.org. The resulting release
-images would not be considered reproducible in this case, because the
-environment used to deploy them cannot be reproduced.
-
-Read through the configuration section at the top of the script, and then run
-it using: `python do-release.py`. The script is designed so that if the release
-fails partway through, you can run the script again and it will resume from
-where it left off. Ensure you have enough disk space for all deployed images:
-the script required 30GB of space during the Baserock 14.23 release.
-
-The script assumes that you have appropriate credentials to upload files to the
+The upload script assumes that you have appropriate credentials to upload files to the
 servers using rsync. If a password is required, rsync will prompt for your
 password at that stage of the script. If you rely on SSH agent forwarding to
 provide access, and are leaving the release script running overnight, remember
 that the machine running your SSH agent must **also** remain running overnight!

-> **Note**: This script is quite new and may need to be tweaked. Although it tries to
-> some extent to be robust, if it aborts while creating or processing a file you
-> should check that the file has been deleted before running the script again,
-> to be doubly sure that there are no corrupt files in the release.
-
-[promote.py script]: https://bitbucket.org/richardipsum/baserock/src/f6503c0c68e5f21463faf82d2ccc3c214603ef91/promote.py?at=master
-[scripts/do-release.py]: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/plain/scripts/do-release.py
-
 GENIVI Baseline release steps
 -----------------------------

@@ -236,15 +151,11 @@
 Announcing the release
 ----------------------

-The script completes when all images and artifacts are successfully uploaded to
-public directories on the appropriate servers.
-
-Once it completes and the release is available, do the following:
+Once the `release-upload` script completes successfully:

-1. Update the 'current' symlinks to point to the new versions of the files.
-2. Update all pages on wiki.baserock.org that refer to the previous release
+1. Update all pages on `wiki.baserock.org` that refer to the previous release
    number to the new release number.
-3. Send release notes to baserock-announce@baserock.org and
+2. Send release notes to baserock-announce@baserock.org and
    baserock-dev@baserock.org.

 Announcing the GENIVI release