Stage 12 — Release-Blocking Issues

What class of issue this is

Stage 12 is maintainer-adjacent: the issues that can hold a release — a regression against a shipped version, a CVE-class security fix, a snapshot/API compatibility break, a data-correctness bug that affects production microVMs. The skill is no longer "fix the code" (you can, by now); it is the judgment to decide whether a given issue blocks a release or merely waits for the next one, and to execute the fix under the constraints that judgment imposes — backports, the support policy, the CHANGELOG, coordinated disclosure. This is the stage where you think like a member of the AWS team that owns the project.

Concretely, a Stage 12 contribution is one of:

• A regression fix: something that worked in version X and broke in X+1, found by a user or by CI, that must be fixed (and likely backported) before the next release.
• A CVE-class security fix: a vulnerability handled through coordinated disclosure, fixed across the supported release lines, often embargoed until release (e.g. the virtio-PCI CVE-2026-5747 was fixed in 1.14.4 and 1.15.1 — verify the specifics on the tracker/CHANGELOG).
• A compatibility-break fix: an API or snapshot change that breaks a contract customers depend on and must be corrected before it ships, or reverted if it already did.
• A triage call: assessing an incoming issue's severity, priority, and release impact — the decision itself is the contribution.

Why it's at this difficulty

Everything above this is "make a correct change." Stage 12 adds the question "correct change, but does it gate the release, and what does fixing it cost downstream?" — a question that requires the support policy, the release cadence, the threat model, and the backport machinery all at once, plus the authority (or the relationship with maintainers) to act on the answer. It is maintainer responsibility; most contributors participate by surfacing release-impacting issues with the right evidence rather than by deciding. Read the release process, the maintainer mindset, and compatibility.

What you must already understand

• The versioning and support policy. Firecracker versions as vMAJOR.MINOR.PATCH; releases have a support window and patch releases backport fixes. Find the policy and the current lines:

rg -n "support|maintenance|release|backport|EOL|policy" docs/ CHARTER.md 2>/dev/null | head
sed -n '1,40p' CHANGELOG.md          # the structure: Added/Changed/Fixed/Removed/Deprecated/Security
git tag --list 'v*' | tail -20       # the released versions you might backport to

• What makes something release-blocking. A regression against a supported version, a security fix, a data-loss/corruption bug (snapshot restore, durability), or a broken compatibility contract. A new-feature gap is not release-blocking; a thing that never worked is not a regression.

• The mechanics: a fix on main, then backports to the affected release branches; the CHANGELOG.md entry under the right heading (### Security for CVEs); milestone/Priority: labels; and, for security, coordinated disclosure (AWS Security, embargo until the patched releases ship — SECURITY.md).

gh issue list --repo firecracker-microvm/firecracker --state open \
  --search "label:\"Priority: High\" sort:updated-desc" --limit 30     # verify the label string
rg -n "milestone|backport|release branch|cherry-pick" CONTRIBUTING.md docs/ | head

Is it release-blocking? A decision table

The two questions that resolve most cases: (1) Did something that used to work stop working? (regression → likely blocking). (2) Can it lose/leak customer data or escape isolation? (corruption/security → blocking). If neither, it almost certainly waits.

How to approach one — worked example: a regression

Illustrative of the pattern.

Symptom: a user reports that a microVM config that booted on v1.N fails on v1.N+1. You suspect a regression. The contribution starts with proving it is one and bounding it.

Step 1 — confirm it's a regression and bisect it

# Reproduce on the new version, then confirm it worked on the old one:
git checkout v1.N      && tools/devtool build && ./firecracker --config-file repro.json   # works
git checkout v1.N+1    && tools/devtool build && ./firecracker --config-file repro.json   # fails
# Find the commit that introduced it:
git bisect start v1.N+1 v1.N
git bisect run sh -c 'tools/devtool build && ./firecracker --config-file repro.json'

The bisect output names the culprit commit — that, plus the two-version reproduction, is the evidence that makes it release-blocking. Post it on the issue with the Priority/severity read.

Step 2 — fix on main, then plan the backport

Fix the root cause on main with a regression test that would have caught it (the fix's value is the test as much as the code). Then identify which release branches need the backport:

git tag --list 'v*'                      # which supported lines contain the bad commit?
git log --oneline <culprit>..main -- <file>   # what else changed there (does the fix apply cleanly?)

The backport is a cherry-pick of the same fix onto each affected release branch, with its own PR and CHANGELOG entry. Keep the fix minimal so it cherry-picks cleanly across lines.

Step 3 — CHANGELOG and the release note

--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ ## [Unreleased]
 ### Fixed
+- Fixed a regression introduced in v1.N+1 where <config> failed to boot ([#NNNN](...)).

For a security fix the heading is ### Security and the disclosure timeline (embargo until the patched releases ship) is coordinated with AWS Security, not negotiated in a public thread.

How a CVE-class fix differs

Illustrative; the real process is SECURITY.md + AWS Security coordination.

• It starts private. The vulnerability is reported to AWS Security, not as a public issue. The fix is developed under embargo.
• It ships across all supported lines at once, in coordinated patch releases (the way CVE-2026-5747 landed in 1.14.4 and 1.15.1 — verify on the CHANGELOG), so users on every line can patch simultaneously.
• The public artifacts (PR, CHANGELOG ### Security, advisory) appear at release, never before.
• As a contributor your role is to report privately and assist under embargo — never to publish a reproduction. Disclosing an exploit early is the most serious process violation in this project.

What a good contribution looks like here

• The triage call is evidence-backed. A two-version reproduction and a bisect for a regression; a clear corruption/escape demonstration (privately, for security) — not an assertion of severity.
• The fix is minimal and backportable. It cherry-picks cleanly onto the affected release branches; a sprawling fix that won't backport is a liability on a release timeline.
• A regression test ships with it that would have caught the break — the durable value.
• The CHANGELOG and milestone are correct: right heading (### Security for CVEs), right release, backport entries on each line.
• Security follows coordinated disclosure: private report, embargoed fix, simultaneous releases, public artifacts only at release.
• You knew when not to block. Correctly arguing that an issue is not release-blocking (a missing feature, a never-worked path) is as valuable as catching one that is.

Graduation criteria — operating at this level when

• You have helped triage at least one release-impacting issue — supplying the reproduction, bisect, and severity read that let a maintainer make the call (or making it yourself, if you are one).
• You can apply the decision table cold: regression vs missing-feature, corruption/escape vs inconvenience, and route each appropriately.
• You can fix on main and backport cleanly to the supported release lines, with the right CHANGELOG entries.
• You understand coordinated disclosure and would never publish a security reproduction ahead of the patched releases.

You have now climbed the whole ladder — from a docs typo to the judgment that holds a release. The roadmap's job is done; the rest is sustained, high-quality contribution over months and years, which is what actually makes maintainership a realistic outcome. Return to the roadmap index to revisit any rung, and read the maintainer mindset for where the path leads next.