Update release checklist (various process tweaks)

Ensure the release checklist reflects our current release process:

  - add an additional deadline for introducing code changes ("code
    freeze"); only test and documentation tweaks can be applied to
    pending releases after this deadline passes,

  - notify Support and Marketing about an impending release earlier in
    the process so that they have time to schedule a release note review
    before the tagging deadline,

  - examine current test results on all platforms in advance, to prevent
    diagnosing and addressing test failures in the last minute before
    the tagging deadline,

  - check Perflab results earlier in the process to leave some room for
    addressing any potential problems before code freeze,

  - ensure empty release notes for the next set of releases are prepared
    after public release.

diff --git a/.gitlab/issue_templates/Release.md b/.gitlab/issue_templates/Release.md
index 1933772bac49d7418a20ace800de874ed857b882..8384fbe71d1fe979c622f8707e5f99fda959c62a 100644 (file)
--- a/.gitlab/issue_templates/Release.md
+++ b/.gitlab/issue_templates/Release.md
@@ -1,21 +1,28 @@
 ## Release Schedule
 
+**Code Freeze:**
+
 **Tagging Deadline:**
 
 **Public Release:**
 
 ## Release Checklist
 
-## 2 Working Days Before the Tagging Deadline
+### Before the Code Freeze
 
+ - [ ] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
+ - [ ] ***(QA)*** Ensure there are no permanent test failures on any platform.
+ - [ ] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
  - [ ] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
  - [ ] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
  - [ ] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
 
-## Before the Tagging Deadline
+### Before the Tagging Deadline
 
- - [ ] ***(QA)*** Inform Support/Marketing of impending release (and give estimated release dates).
- - [ ] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
+ - [ ] ***(QA)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found.
+ - [ ] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
+ - [ ] ***(Support)*** Check release notes, ask QA to correct any mistakes found.
+ - [ ] ***(Marketing)*** Check release notes, ask QA to correct any mistakes found.
  - [ ] ***(SwEng)*** Update API files for libraries with new version information.
  - [ ] ***(SwEng)*** Change software version and library versions in `configure.ac` (new major release only).
  - [ ] ***(SwEng)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
@@ -25,12 +32,11 @@
  - [ ] ***(SwEng)*** Update `version`.
  - [ ] ***(SwEng)*** Build documentation on `docs.isc.org`.
  - [ ] ***(QA)*** Check that all the above steps were performed correctly.
- - [ ] ***(QA)*** Check that the contents of release notes match the merge requests comprising the releases.
  - [ ] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
  - [ ] ***(SwEng)*** Tag the releases[^2].  (Tags may only be pushed to the public repository for releases which are *not* security releases.)
  - [ ] ***(SwEng)*** If this is the first tag for a release (e.g. beta), create a release branch named `release_v9_X_Y` to allow development to continue on the maintenance branch whilst release engineering continues.
 
-## Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
+### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
 
  - [ ] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
  - [ ] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
@@ -41,7 +47,7 @@
  - [ ] ***(QA)*** Notify Support that the releases have been prepared.
  - [ ] ***(Support)*** Send out ASNs (if applicable).
 
-## On the Day of Public Release
+### On the Day of Public Release
 
  - [ ] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
  - [ ] ***(Support)*** Place tarballs in public location on FTP site.
@@ -60,6 +66,7 @@
  - [ ] ***(SwEng)*** Push tags for the published releases to the public repository.
  - [ ] ***(SwEng)*** Merge the automatically prepared `prep 9.X.Y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_X`).
  - [ ] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check:sid:amd64` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
+ - [ ] ***(QA)*** Prepare empty release notes for the next set of releases.
 
 [^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.