The merge cascade — branch-protection require-up-to-date (which stays, per the hard rule) × serial merges × the slow/wedge-prone E2E matrix — makes multi-PR batches drain painfully (acute in the #373 Robolectric epic: ~6 PRs, serial, each a full ~15-min E2E, hand-bumped one at a time). GitHub's native merge queue is org/enterprise-only and JMR-dev is a user account, so it's unavailable.
Mergify is a third-party GitHub App providing a real merge queue — batching (merge N PRs together with ONE CI run), speculative checks, auto-rebase/up-to-date, priority — and is free for open source. It solves the throughput problem the RIGHT way: it keeps require-up-to-date and does the up-to-date-ing automatically/speculatively, replacing the manual serial-bump grind.
Goal
An Opus agent investigates Mergify and proposes an integration spec (proposal only — do NOT activate it). Cover:
How Mergify's merge queue works and how it coexists with require-up-to-date (kept), the single CI passed gate, and the repo's merge-commit policy.
A proposed .mergify.yml: queue rules (merge conditions — CI passed green, P-label, etc.), batching config (the big win for test-only batches), priority mapped to our P0–P9 labels, merge method = merge commit.
How it replaces the manual serial-bumping and the already-disabledautoupdate.yml/ci-trigger.yml (mothballed traffic-controller) — see ci-merge-cascade.
Free-for-OSS eligibility + setup (install the app, permissions, config), and interaction with the E2E path-filter (#399/#402), sharding (#372), and wedge diagnostics (#404/#406).
Risks/tradeoffs (third-party in the merge path; config complexity; speculative-check CI cost).
Deliverable
A written spec (doc) + a proposed.mergify.yml (clearly marked NOT-yet-active, e.g. as a code block or *.proposed file — do NOT commit a live .mergify.yml) for the maintainer to review before adopting. Must not weaken require-up-to-date.
## Context
The merge cascade — branch-protection **require-up-to-date** (which stays, per the hard rule) × serial merges × the slow/wedge-prone E2E matrix — makes multi-PR batches drain painfully (acute in the #373 Robolectric epic: ~6 PRs, serial, each a full ~15-min E2E, hand-bumped one at a time). GitHub's **native** merge queue is org/enterprise-only and JMR-dev is a **user account**, so it's unavailable.
**Mergify** is a third-party GitHub App providing a real merge queue — **batching** (merge N PRs together with ONE CI run), speculative checks, auto-rebase/up-to-date, priority — and is **free for open source**. It solves the throughput problem the RIGHT way: it keeps require-up-to-date and does the up-to-date-ing automatically/speculatively, replacing the manual serial-bump grind.
## Goal
An Opus agent **investigates Mergify and proposes an integration spec** (proposal only — do NOT activate it). Cover:
- How Mergify's merge queue works and how it coexists with **require-up-to-date** (kept), the single `CI passed` gate, and the repo's merge-commit policy.
- A proposed `.mergify.yml`: queue rules (merge conditions — `CI passed` green, P-label, etc.), **batching** config (the big win for test-only batches), priority mapped to our **P0–P9 labels**, merge method = merge commit.
- How it replaces the manual serial-bumping and the already-**disabled** `autoupdate.yml`/`ci-trigger.yml` (mothballed traffic-controller) — see [[ci-merge-cascade]].
- Free-for-OSS eligibility + setup (install the app, permissions, config), and interaction with the E2E path-filter (#399/#402), sharding (#372), and wedge diagnostics (#404/#406).
- Risks/tradeoffs (third-party in the merge path; config complexity; speculative-check CI cost).
## Deliverable
A written spec (doc) + a **proposed** `.mergify.yml` (clearly marked NOT-yet-active, e.g. as a code block or `*.proposed` file — do NOT commit a live `.mergify.yml`) for the maintainer to review before adopting. **Must not weaken require-up-to-date.**
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Context
The merge cascade — branch-protection require-up-to-date (which stays, per the hard rule) × serial merges × the slow/wedge-prone E2E matrix — makes multi-PR batches drain painfully (acute in the #373 Robolectric epic: ~6 PRs, serial, each a full ~15-min E2E, hand-bumped one at a time). GitHub's native merge queue is org/enterprise-only and JMR-dev is a user account, so it's unavailable.
Mergify is a third-party GitHub App providing a real merge queue — batching (merge N PRs together with ONE CI run), speculative checks, auto-rebase/up-to-date, priority — and is free for open source. It solves the throughput problem the RIGHT way: it keeps require-up-to-date and does the up-to-date-ing automatically/speculatively, replacing the manual serial-bump grind.
Goal
An Opus agent investigates Mergify and proposes an integration spec (proposal only — do NOT activate it). Cover:
CI passedgate, and the repo's merge-commit policy..mergify.yml: queue rules (merge conditions —CI passedgreen, P-label, etc.), batching config (the big win for test-only batches), priority mapped to our P0–P9 labels, merge method = merge commit.autoupdate.yml/ci-trigger.yml(mothballed traffic-controller) — see ci-merge-cascade.Deliverable
A written spec (doc) + a proposed
.mergify.yml(clearly marked NOT-yet-active, e.g. as a code block or*.proposedfile — do NOT commit a live.mergify.yml) for the maintainer to review before adopting. Must not weaken require-up-to-date.