Skip to content

Pull-request process

  • Topic branches off main. Short names: eventing-dlq-replay, data-postgres-streaming.
  • Don’t fork the repo unless you’re outside the org.
  • Rebase rather than merge to keep history linear.
  • Imperative subject line, ≤ 72 chars.
  • Body describes the why when non-obvious.
  • One logical change per commit. If you can’t summarise the commit in one line, split it.

The repo’s PR template asks for:

  • Scope summary.
  • Maturity-label impact (do any packages graduate?).
  • Test coverage notes.
  • Benchmark notes (if applicable).
  • Docs notes.
  • All required checks green: build, test, lint, format.
  • One reviewer (two for engine-surface changes).
  • Author resolves all request-changes.
  • Squash-merge unless the commit history is intentional.

The default mode for CephalonEngine is autonomous continuous shipping — pick a slice, ship it, merge it, repeat. If a change is risky or cross-cutting, an issue is raised first.

  • Topic branches live no longer than a sprint.
  • Stale branches are pruned weekly.