release-procedure: Fix some formatting issues

Signed-off-by: Fabian Deutsch <[email protected]>

docs/release-procedure.md

@@ -24,11 +24,11 @@ text file on your machine. Make sure you don't place this in shared storage.
 
 **Example of exporting key to file**
 
-```gpg --export-secret-key -a <your-email-address> > ${HOME}/gpg-private```
+    gpg --export-secret-key -a <your-email-address> > ${HOME}/gpg-private
 
 **Example of putting passphrase in file**
 
-```echo "<insert your passphrase here>" > ${HOME}/gpg-passphrase```
+    echo "<insert your passphrase here>" > ${HOME}/gpg-passphrase
 
 2. **Github API token file used for accessing the github api**
 
@@ -37,7 +37,7 @@ ability to access github repositories. That's it.
 
 [Instructions for creating _classic_ access tokens](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token)
 
-**Place your token in a text file such as** ```${HOME}/github-api-token```
+**Place your token in a text file such as** `${HOME}/github-api-token`
 
 ## Release Tool Usage Examples
 
@@ -47,47 +47,46 @@ what release you want to make.
 
 Place the paths to your credential files in the following environment variables.
 
-```
-export GPG_PRIVATE_KEY_FILE="${HOME}/gpg-private"
-export GPG_PASSPHRASE_FILE="${HOME}/gpg-passphrase"
-export GITHUB_API_TOKEN_FILE="${HOME}/github-api-token"
-```
+    export GPG_PRIVATE_KEY_FILE="${HOME}/gpg-private"
+    export GPG_PASSPHRASE_FILE="${HOME}/gpg-passphrase"
+    export GITHUB_API_TOKEN_FILE="${HOME}/github-api-token"
+
+> **Note**
+> The release tool is running in a container. SELinux can lead to file
+> access issues. Thus look at your audit log if you experience file
+> access issues.
 
 Now you can use the release tool to do whatever you'd like. Note that you can
-use the ```--dry-run=true``` argument to test a change before executing it.
+use the `--dry-run=true` argument to test a change before executing it.
 
 **Example: creating a new release branch with the initial release candidate v0.31.0-rc.0**
-```
-hack/release.sh --new-branch release-0.31 --new-release v0.31.0-rc.0 --dry-run=false
-```
+
+    hack/release.sh --new-branch release-0.31 --new-release v0.31.0-rc.0 --dry-run=false
 
 **Example: Creating a new rc v0.31.0-rc.0**
-```
-hack/release.sh --new-release v0.31.0-rc.0 --dry-run=false
-```
+
+    hack/release.sh --new-release v0.31.0-rc.0 --dry-run=false
 
 **Example: Promoting a release candidate v0.31.0-rc-1 to official v0.30.0 release.**
-```
-hack/release.sh --promote-release-candidate v0.31.0-rc-1 --dry-run=false
-```
+
+    hack/release.sh --promote-release-candidate v0.31.0-rc-1 --dry-run=false
 
 **Example: Creating a patch release v0.31.1. The branch will automatically be detected.**
-```
-hack/release.sh --new-release v0.31.1 --dry-run=false
-```
+
+    hack/release.sh --new-release v0.31.1 --dry-run=false
 
 ## Creating New Minor Releases
 The release process is mostly automatic and consists of the following steps:
 
 1. Create the branch and initial RC.
 
-   ```hack/release.sh --new-branch $RELEASE_BRANCH --new-tag ${TAG}.rc.0```
+   `hack/release.sh --new-branch $RELEASE_BRANCH --new-tag ${TAG}.rc.0`
 
-2. Wait 5 business days
+2. Continue to create RC's according to the release schedule
 
-3. Promote RC to official release if no blockers exist.
+3. Once it is time for an official release, promote the most recent RC if no blockers exist.
 
-   ```hack/release.sh --promote-release-candidate ${TAG}.rc.0```
+   `hack/release.sh --promote-release-candidate ${TAG}.rc.5`
 
 4. Wait for [Prow job](https://prow.ci.kubevirt.io/?repo=kubevirt%2Fkubevirt) to
    finish, and check that the binary artifacts got attached to the release
@@ -109,7 +108,7 @@ The release itself is only a git signed tag as it's used for minor releases as w
 
 1. Create the patch release. Note that the branch is automatically detected.
 
-   ```hack/release.sh --new-tag ${TAG}```
+   `hack/release.sh --new-tag ${TAG}`
 
 2. Wait for [Prow job](https://prow.ci.kubevirt.io/?repo=kubevirt%2Fkubevirt) to
    finish, and check that the binary artifacts got attached to the release
@@ -154,14 +153,12 @@ is `release-0.6`).
 
 Release notes are automatically generated by our release tool. The notes are
 sourced from the delta of PRs merged since the last official release. The text
-from those PRs are sourced directly from the ```release-notes``` section in
+from those PRs are sourced directly from the `release-notes` section in
 each PRs description.
 
 Below is an example of getting the release notes for v0.31.0-rc.0
 
-```
-git show v0.31.0-rc.0
-```
+    git show v0.31.0-rc.0
 
 # Handling Release Blockers
 
@@ -189,21 +186,21 @@ that the release blocker labels should remain even after an issue or PR is close
 **Example: Signalling a PR/Issue should block the next release branch.** This
 Will prevent a new release branch from being cut until PR/Issue is closed.
 
-```/release-blocker main```
+    /release-blocker main
 
 **Example: Signalling a PR/Issue should block the official release of a
 stable branch** This will prevent any existing RCs from being promoted
 to an official release. A new RC will only able to be created once this
 Issue/PR is closed.
 
-```/release-blocker release-0.31```
+    /release-blocker release-0.31
 
 **Example: Canceling a release-blocker.** This will remove the signal that
 an Issue/PR is a blocker. This should only be done if the issue truly
 isn't a blocker.
 
-```/release-blocker cancel release-0.31```
+    /release-blocker cancel release-0.31
 
 and canceling a blocker on main would look like.
 
-```/release-blocker cancel main```
+    /release-blocker cancel main