BIND 9 MR titles & descriptions
The MR title + description ARE the release note — ISC's release tooling
generates doc/notes/ entries from merged MRs. Audience: system
administrators, not engineers.
Security framing: bug vs vulnerability
Local-filesystem misbehavior is a BUG, not a vulnerability. BIND treats
the local filesystem as trusted: no "privilege escalation", "local
attacker", "exploit", "vulnerability", or CVE/severity language for
symlink-following, local TOCTOU, or service-account issues. Describe it
operationally ("X followed symlinks and could overwrite the wrong
file"). Reserve security framing for remote or protocol surfaces:
network input, DNS message parsing, configuration from an untrusted
publisher, signed-zone integrity. Defensive code (lstat/O_NOFOLLOW,
mkstemp) remains the right fix — only the framing changes.
Title
Short (under ~70 chars), leading with the user-visible impact (crash,
wrong answers, resource exhaustion, new capability).
Description
- One short paragraph (typically 2–4 sentences), single flow: the
operational problem, then the fix. No section headings, no bullet
lists, no restating of the commit message.
- Describe the trigger in operational terms — what the admin configures
or does, what they observe. No function/struct/variable names, no
programming jargon (TOCTOU, NULL dereference, use-after-free...).
- Don't list individual changes; summarize the combined effect.
Test-only or developer-only options get at most a brief mention at
the end.
- Don't add
Closes #NNNN.
- Scale to the change: a one-line fix gets ~3 sentences, not a
structured template.
Internal-only exception: for refactors with no operator-visible
impact the audience is developers — naming internal functions is fine —
but the title and description stay just as terse.
Hard rules
- NO
Assisted-by: in MR titles or descriptions — that trailer belongs
on commits; in release-note material it is noise for sysadmins.
- NEVER create or edit files under
doc/notes/ — those are generated
from merged MRs. A branch without a doc/notes/ change is not
missing anything; do not flag it in reviews. "Needs a release note"
means: write a good MR title and description.
- Hand the finished title/description to the user as text; never open
the MR yourself (see the bind-commit skill's boundary).
1---2name: bind-mr-description3description: Drafting BIND 9 merge-request titles and descriptions — they feed the generated release notes, so the audience is system administrators. Use whenever writing or reviewing an MR title/description, when a change "needs a release note", or when tempted to touch doc/notes/.4---56# BIND 9 MR titles & descriptions78The MR title + description ARE the release note — ISC's release tooling9generates `doc/notes/` entries from merged MRs. Audience: system10administrators, not engineers.1112## Security framing: bug vs vulnerability1314Local-filesystem misbehavior is a BUG, not a vulnerability. BIND treats15the local filesystem as trusted: no "privilege escalation", "local16attacker", "exploit", "vulnerability", or CVE/severity language for17symlink-following, local TOCTOU, or service-account issues. Describe it18operationally ("X followed symlinks and could overwrite the wrong19file"). Reserve security framing for remote or protocol surfaces:20network input, DNS message parsing, configuration from an untrusted21publisher, signed-zone integrity. Defensive code (lstat/O_NOFOLLOW,22mkstemp) remains the right fix — only the framing changes.2324## Title2526Short (under ~70 chars), leading with the user-visible impact (crash,27wrong answers, resource exhaustion, new capability).2829## Description3031- One short paragraph (typically 2–4 sentences), single flow: the32 operational problem, then the fix. No section headings, no bullet33 lists, no restating of the commit message.34- Describe the trigger in operational terms — what the admin configures35 or does, what they observe. No function/struct/variable names, no36 programming jargon (TOCTOU, NULL dereference, use-after-free...).37- Don't list individual changes; summarize the combined effect.38 Test-only or developer-only options get at most a brief mention at39 the end.40- Don't add `Closes #NNNN`.41- Scale to the change: a one-line fix gets ~3 sentences, not a42 structured template.4344**Internal-only exception:** for refactors with no operator-visible45impact the audience is developers — naming internal functions is fine —46but the title and description stay just as terse.4748## Hard rules4950- NO `Assisted-by:` in MR titles or descriptions — that trailer belongs51 on commits; in release-note material it is noise for sysadmins.52- NEVER create or edit files under `doc/notes/` — those are generated53 from merged MRs. A branch without a `doc/notes/` change is not54 missing anything; do not flag it in reviews. "Needs a release note"55 means: write a good MR title and description.56- Hand the finished title/description to the user as text; never open57 the MR yourself (see the bind-commit skill's boundary).
isc-projects