It was agreed that the monthly CI container image rebuild should be done
manually rather than be automated. This allows us to have control over
when things could break and the end of the release cycle is the most
convenient time to have that happen.
Update the release checklist to incorporate some minor tweaks that we
have been applying manually for the past few months as a result of
release process evolution.
Rework the Security Incident Handling Checklist so that it does not only
contain the SWENG-side steps for handling a security incident, but also
all the other steps required by ISC procedures.
The util/release-tarball-comparison.sh script compares a release-ready
BIND 9 tarball to a temporary BIND 9 tarball created from the same
signed Git tag to ensure that their content does not differ
(significantly).
Add an item to the release checklist to make sure regression tests
reproducing publicly disclosed security issues are eventually merged
into each maintained branch.
Add an item to the CVE issue template which calls for drafting the
security advisory early in the security incident handling process. The
intention is to ensure there is enough time to review and polish ISC
security advisories before they get published.
Tweak the release checklist to make sure we carefully consider all
confidential issues before opening them up to the public. This change
is intended as a safeguard against accidentally disclosing too much
information about a security vulnerability before our users get a chance
to patch it.
Add an item to the release checklist to make sure eligible customers get
notified about the location of the latest version of BIND Subscription
Edition upon its release.
Add an item to the release checklist to make sure confidential issues
assigned to the relevant milestone are made public after the BIND
versions addressing them are released.
- First merge release branches to maintenance branches, then push
tags. If tags are pushed first and a given set of releases contains
security fixes, the push will be rejected by a server-side Git hook.
- Update ABI check job name.
- Add an item for updating QA tools used in GitLab CI after each
public release.
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.
The reference BIND version used in the ABI check CI job is not
determined automatically - it needs to be updated after each BIND
release. Reflect that fact in the release checklist to make sure the
ABI check CI job is always comparing current code with the latest BIND
release on a given branch.
Make the release checklist match the current release process better by
adding missing steps, rearranging existing ones, reassigning
responsibilities, and dividing the list into sections (by due date).
