Release, Review & Governance Practices

The Contributor Mindset section answered the first-person question: how do I behave so my work gets accepted? This section answers the inverted, second-person question that decides whether your PR merges or rots: what are the people on the other side of the table actually doing? What does a maintainer read in your diff, why does a five-line change to a device get a security interrogation, how does a fix become a release, and — the part that trips up engineers arriving from foundation-governed projects — who decides any of it, and what does that mean for your influence?

Firecracker is open source, Apache-2.0, developed in the open on GitHub. But it is not governed the way OpenSearch, Kubernetes, or an Apache project is governed. There is no foundation. There is no Technical Steering Committee. There is no GOVERNANCE.md, no [VOTE] thread, no public ladder of community committers you climb onto. Firecracker is single-vendor governed: a dedicated AWS team owns it as production infrastructure — it is what runs your Lambda functions and Fargate tasks — and that ownership reshapes everything in this section. Not by closing the door to external contributors, but by changing what "earning a seat" looks like. This section is the honest map of that reality.

Note: If you are coming from the sibling OpenSearch curriculum, unlearn the foundation reflexes. OpenSearch moved to the Linux Foundation in 2024 specifically to become vendor-neutral; its TSC sets cross-project direction; its release manager rotates through the community. Firecracker is the opposite design on purpose. Where this section says "the maintainers decide," it means a specific AWS team decides — and the gap between contributing and deciding is wider here than in a foundation project. Be clear-eyed about that; it is the single most important thing this section teaches.

This section does not hold your hand. It points you at the real artifacts — CONTRIBUTING.md, CHARTER.md, MAINTAINERS.md, docs/RELEASE_POLICY.md, SECURITY.md, the DCO bot, the CI gates — and makes you run gh and rg against a live checkout to confirm them, because process docs drift between releases just like code does.

How Firecracker Is Governed, Released, and Reviewed (the 90-second version)

                          AWS Firecracker team (the maintainers)
                                       │  owns direction, merges code,
                                       │  cuts releases, handles security
        ┌──────────────────────────────┼──────────────────────────────┐
        ▼                              ▼                               ▼
   GOVERNANCE                      REVIEW                          RELEASE
   single-vendor;                 fork-and-pull PR vs `main`;      SemVer; CHANGELOG;
   CHARTER.md scope;              DCO sign-off (no CLA);           release branches;
   MAINTAINERS.md;                ≥2 maintainer approvals;         docs/RELEASE_POLICY.md;
   no foundation/TSC;             CI: fmt/clippy -D/build/         CVE → private fix,
   firecracker-                   pytest/Kani;                     coordinated release
   maintainers@amazon.com         a maintainer merges             (e.g. 1.14.4 / 1.15.1)

Everything an external contributor touches is the REVIEW column. The GOVERNANCE and RELEASE columns are run by the AWS team; your job is to understand them well enough to make your contributions land — to write the PR the reviewer doesn't have to fight, to scope the change so it doesn't threaten a release, to know which area's de facto owner you need on board.

The Seven Chapters and How They Fit

This section is one index plus seven essays. Read them in order the first time; afterward they stand alone. The first three are about how work happens and gets reviewed, the next two about how maintainers think and how releases ship, and the last two about the legal and craft foundations that earn you the right to be taken seriously.

Chapters 1, 2, 6, and 7 are immediately actionable for any first-time contributor. Chapters 3, 4, and 5 are maintainer- and release-facing — but read them early, because understanding why a maintainer blocks a device on attack-surface grounds, or why a snapshot-format change is nearly un-mergeable, is what stops your PR from stalling.

How This Mirrors the Contributor Mindset Section

This section and the Contributor Mindset section are two halves of one coin. The mindset section is what you do; this section is what the maintainer reviewing you, the release process shipping you, and the AWS team governing the project do. Several mindset chapters have a governance mirror here — read your own behavior there, then read the receiving end here, and your PRs converge on what merges.

Prerequisites

Before this section is fully useful, you should have a clone of the engine and have skimmed its process documents. They are the authoritative ground truth; this section explains the why behind them, it is not a substitute.

git clone https://github.com/firecracker-microvm/firecracker.git ~/fc-src
cd ~/fc-src
# Confirm the governance and process artifacts this section keeps pointing at:
ls CONTRIBUTING.md CHARTER.md MAINTAINERS.md SECURITY.md CHANGELOG.md
ls docs/RELEASE_POLICY.md
# Who currently owns the merge button (verify on your branch — the roster changes):
sed -n '1,80p' MAINTAINERS.md
# The scope statement that decides what gets accepted at all:
sed -n '1,60p' CHARTER.md

You should also have configured DCO sign-off (git config is fine; the mandatory part is the Signed-off-by: trailer that git commit -s produces — see licensing-and-dco.md), and have the build/test loop working (tools/devtool build, tools/devtool test) from Lab 1.1 and Lab 1.2.

If you intend to follow the capstone, you will exercise nearly all of this: a real PR reviewed under the ≥2-approval rule, defended against the maintainer's compatibility and attack-surface questions, and — if it's a fix — shipped under the release policy.

You've Absorbed This Section When…

You can do the following without looking them up:

1. Name the CI gates that block a merge (fmt/style, clippy -D warnings, build, pytest integration, Kani where labelled) and say what each protects.
2. Explain why Firecracker uses review-then-merge with ≥2 maintainer approvals, and who actually presses merge.
3. Predict, before opening it, whether a change belongs as a plain bug fix, an enhancement issue, or a design proposal — and which channel drives consensus for each, given there is no public Slack.
4. Read a diff that touches the REST API, the snapshot format, or a device, and predict whether a maintainer blocks it on compatibility or attack-surface grounds.
5. Trace how a bug fix on main becomes a patch release, including the CHANGELOG entry, the release branch, and the backport — and how a CVE fix (e.g. the 1.14.4 / 1.15.1 fix for the PCI-transport CVE) is handled differently.
6. State, accurately and without bitterness, the realistic ceiling for an external contributor under single-vendor governance, and the concrete way to push that ceiling higher.
7. Reproduce what a contributor must get right on licensing: the Apache-2.0 header, the DCO Signed-off-by, the NOTICE/THIRD-PARTY files, and the cargo-deny dependency gate.

Next: Communication Channels and Consensus — where the work actually happens when there is no Slack, no forum, and no mailing list you can post to.