# Steering: email-patch governance

Solnix governs changes by **email and patches**, not forge pull requests. This
is deliberate: it keeps the archive open, tool-agnostic, and durable, and it
puts review in a threaded, citable medium.

## Lists

- `hackers@solnix.io` — patches and technical discussion. Public, archived,
  readable over NNTP and IMAP.
- `security@solnix.io` — embargoed security work. Private.

(There is intentionally **no** `patches@` or `commits@` — the two lists above
are the whole surface.)

## How a change lands

1. A patch is sent to `hackers@` (git-send-email style), **signed** (SSH or GPG)
   so committer identity is verifiable.
2. Review by `+1` / `0` / `-1`. An **owner `-1` hard-blocks**. Silence past the
   transition timer can be a pocket-veto where a quorum path exists.
3. Anything that changes a built artifact also needs a **reproducibility
   quorum** (independent identical hashes) — a *separate* gate from human review.
4. A **distinct post-quorum owner approval** merges it. High-blast-radius changes
   (toolchain, stdenv, seeds) need an **owner quorum**, not a single owner.

## OWNERS and timers

- `OWNERS` files declare who governs each area. The **core team governs OWNERS**.
- Transition timers default to **3 business days**; a thread can tune its own
  with `adjust-timeout:` / `adjust-quorum:` email commands.

## CVEs

The CVE lane is private: build the fix on `security@`, coordinate a simultaneous
fix across supported editions, then disclose. See the `report-a-cve` workflow.

## Two roots of trust that never merge

- **Maintainer governs source** (email → git.solnix.io).
- **Math governs binaries** (N identical hashes → the signer).

Design of record: `infra/docs/design/asset-lifecycle-governance-v2.md`.