From 8ffdeea85d8d73c9f23cc72d7c5a67c1712b7e65 Mon Sep 17 00:00:00 2001 From: John Coffey Date: Sun, 20 Sep 2026 16:09:36 -0700 Subject: [PATCH] Write down how a change reaches main, now that it is enforced main has a ruleset as of today: no force-push, no deletion, and a pull request with a green build to merge. CONTRIBUTING said nothing about any of it, and a contributor's first clue would have been a rejected push. No approving review is required. A review gate nobody can pass is not a gate, and this is a project with one maintainer; the build is the part that has to hold. The section also says why the rule exists rather than only what it is. The weekly release cuts from main on a Monday and ships whatever is there, so main is expected to be releasable continuously -- which makes "not finished" a thing that belongs behind a default-off switch or off main altogether, not a state main passes through on a Thursday. Administrators can bypass. That is written down as being for correcting the tree, not for skipping the path, because an undocumented bypass becomes the normal route. --- CONTRIBUTING.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e2155b2..392caff 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -11,6 +11,25 @@ and it should be worth that. Small fixes — a bug, a typo, a test — need no ceremony. Send them. +## How a change lands + +`main` is protected. It cannot be force-pushed or deleted, and a change +reaches it through a pull request whose `build` check has passed. No approving +review is required — this is a small project and a gate nobody can pass is not +a gate — but the build is not optional. + +So the shape of a change is: a branch, a pull request, a green CI run, a merge. +Branches are deleted on merge. Repository administrators can bypass the rule, +which exists so the maintainer can correct the tree quickly, not so that the +ordinary path can be skipped; use it for an emergency, not for convenience. + +Releases are cut weekly from `main` by `.github/workflows/release.yml`, on +Monday morning UTC, and nothing is released on a quiet week. That is the reason +the rule matters: whatever is on `main` when the run starts is what ships, so +`main` is expected to be releasable at all times rather than at the end of a +piece of work. A change that is not finished should be behind something that +defaults to off, or it should not be on `main` yet. + ## What this repository is INBUXA is a fork of Stalwart, taken under the AGPL-3.0-only half of its dual