Document the hotfix release process

doc/hotfix-process.md

@@ -0,0 +1,57 @@
+Hotfix Release Process
+======================
+
+In the commands below, <RELEASE> and <RELEASE_PREV> are prefixed with a v, ie.
+v1.0.11 (not 1.0.11).
+
+## Create a hotfix branch
+
+Create a hotfix branch from the previous release tag, and push it to the main
+repository:
+
+    $ git branch hotfix-<RELEASE> <RELEASE_PREV>
+    $ git push 'git@github.com:zcash/zcash' hotfix-<RELEASE>
+
+## Merge hotfix PRs
+
+Developer should create hotfix PRs based on the hotfix branch. Each PR should be
+reviewed as normal, and then the following process should be used to merge:
+
+- A CI merge build is manually run, by force-triggering the pr-merge builder
+  with the following fields set:
+
+  - Repository: https://github.com/<DevUser>/zcash
+    - <DevUser> must be in the set of "safe" users as-specified in the CI
+      config.
+  - Branch: name of the hotfix PR branch (not the hotfix release branch).
+
+- A link to the build and its result is manually added to the PR as a comment.
+
+- If the build was successful, the PR is merged via the GitHub button.
+
+## Release process
+
+The majority of this process is identical to the standard release process.
+However, there are a few notable differences:
+
+- When running the release script, use the `--hotfix` flag:
+
+    $ ./zcutil/make-release.py --hotfix <RELEASE> <RELEASE_PREV> <APPROX_RELEASE_HEIGHT>
+
+- To review the automated changes in git:
+
+    $ git log hotfix-<RELEASE>..HEAD
+
+- After the standard review process, use the hotfix merge process outlined above
+  instead of the regular merge process.
+
+- When making the tag, check out the hotfix branch instead of master.
+
+## Post-release
+
+Once the hotfix release has been created, a new PR should be opened for merging
+the hotfix release branch into master. This may require fixing merge conflicts
+(e.g. changing the version number in the hotfix branch to match master, if
+master is ahead). Such conflicts **MUST** be addressed with additional commits
+to the hotfix branch; specifically, the branch **MUST NOT** be rebased on
+master.

doc/release-process.md

@@ -2,6 +2,8 @@ Release Process
 ====================
 Meta: There should always be a single release engineer to disambiguate responsibility.
 
+If this is a hotfix release, please see `./hotfix-process.md` before proceeding.
+
 ## Pre-release
 
 ### Github Milestone
@@ -40,6 +42,11 @@ whole engineering team.
 
 ## Release process
 
+In the commands below, <RELEASE> and <RELEASE_PREV> are prefixed with a v, ie.
+v1.0.9 (not 1.0.9).
+
+### Create the release branch
+
 Run the release script, which will verify you are on the latest clean
 checkout of master, create a branch, then commit standard automated
 changes to that branch locally: