TOP PRIORITY: consolidate all open PRs onto one next branch, one PR #91

New Issue

2026-08-10T14:30:53+02:00

clawbot commented

2026-08-10 14:30:53 +02:00

This outranks all feature work in this repo. Do it before anything else.

Owner instruction, sneak 2026-08-10:

why are there so many PRs in one repo? there should be one and only one PR open at a time for the next milestone, as we squash commits on main and i'm tired of merge conflicts after merging one bc i don't know the order.

He squashes on merge, so a second open PR conflicts the moment the first lands, and the ordering burden falls on him.

What to do

Fold both open PRs onto a single next branch, resolving the conflicts between them yourself:

#59
#88

They overlap on Dockerfile, Makefile and TODO.md. #59 first, since #88 is the cheaper rebase of the two.

Definition of done

One next branch containing both as separate issue-closing commits, each message ending (closes #N).
Exactly ONE open PR in this repo: next -> main, titled for the milestone.
make check green on the combined result — verified after conflict resolution, because a clean textual merge can still break the build.
Both superseded PRs closed with a comment saying where their work went, and their branches deleted.
Nothing lost: confirm each original PR's commits are represented in next before closing it.

Model going forward

next is the branch for the NEXT MILESTONE, not the next release; main changes between releases as milestones land. Every worker works in its own clone, pulls next before starting, and pulls and resolves conflicts itself immediately before pushing. Exactly one open PR in this repo at all times from now on.

**This outranks all feature work in this repo. Do it before anything else.** Owner instruction, sneak 2026-08-10: > why are there so many PRs in one repo? there should be one and only one PR open at a time for the next milestone, as we squash commits on main and i'm tired of merge conflicts after merging one bc i don't know the order. He squashes on merge, so a second open PR conflicts the moment the first lands, and the ordering burden falls on him. ## What to do Fold both open PRs onto a single `next` branch, resolving the conflicts between them yourself: - https://git.eeqj.de/sneak/mfer/pulls/59 - https://git.eeqj.de/sneak/mfer/pulls/88 They overlap on `Dockerfile`, `Makefile` and `TODO.md`. #59 first, since #88 is the cheaper rebase of the two. ## Definition of done - One `next` branch containing both as separate issue-closing commits, each message ending ` (closes #N)`. - Exactly ONE open PR in this repo: `next` -> `main`, titled for the milestone. - `make check` green on the combined result — verified after conflict resolution, because a clean textual merge can still break the build. - Both superseded PRs closed with a comment saying where their work went, and their branches deleted. - Nothing lost: confirm each original PR's commits are represented in `next` before closing it. ## Model going forward `next` is the branch for the NEXT MILESTONE, not the next release; `main` changes between releases as milestones land. Every worker works in its own clone, pulls `next` before starting, and pulls and resolves conflicts itself immediately before pushing. Exactly one open PR in this repo at all times from now on.

clawbot commented

2026-08-10 14:46:54 +02:00

Correction to the rule as I originally stated it. sneak, 2026-08-10:

> you can have multiple open PRs per repo if the milestone on next is completed and hasn't been merged to main yet. you can work on the next milestone off of next on a new PR (mark wip). i just don't want one PR per small feature branch

So the target is not "exactly one open PR, always" — it is one PR per milestone, never one per feature branch. A second open PR is legitimate when a finished milestone PR is waiting on sneak and the following milestone has started off next (not off main) under a WIP: title prefix.

The consolidation work here is unchanged: these are per-issue PRs, which is exactly the shape he does not want.

Also done, so nobody has to remember not to merge mid-consolidation: every open PR in this repo is now titled WIP: …, labelled needs-rebase, and assigned to clawbot. Strip the prefix and reassign only when the milestone PR is genuinely ready. His instruction: "don't tell me not to merge things, rename the PRs with WIP: prefix so they aren't mergeable."

Correction to the rule as I originally stated it. sneak, 2026-08-10: > you can have multiple open PRs per repo if the milestone on `next` is completed and hasn't been merged to `main` yet. you can work on the next milestone off of `next` on a new PR (mark wip). i just don't want one PR per small feature branch So the target is not "exactly one open PR, always" — it is **one PR per milestone, never one per feature branch**. A second open PR is legitimate when a finished milestone PR is waiting on sneak and the following milestone has started off `next` (not off `main`) under a `WIP: ` title prefix. The consolidation work here is unchanged: these are per-issue PRs, which is exactly the shape he does not want. Also done, so nobody has to remember not to merge mid-consolidation: every open PR in this repo is now titled `WIP: …`, labelled `needs-rebase`, and assigned to `clawbot`. Strip the prefix and reassign only when the milestone PR is genuinely ready. His instruction: "don't tell me not to merge things, rename the PRs with WIP: prefix so they aren't mergeable."

clawbot commented

2026-08-10 15:20:11 +02:00

Superseded. sneak, 2026-08-10: "branch and pr per issue, landing on next, squash merged by manager on successful review. manager owns dispatching workers to resolve merge conflicts. next is always ready for me to merge to main without notice." And: "manager merges the pr to next i mean, not directly with git."

So do NOT consolidate or close these PRs. Retarget each to base next, squash-merge it there through Gitea on a passed review, and dispatch a worker for any that will not merge cleanly. main is only ever touched by the milestone PR from next, which sneak merges.

Feature branches may be red; next and main must stay green. Create next from main if it does not exist here yet. Drop the WIP: prefixes once retargeted.

Superseded. sneak, 2026-08-10: "branch and pr per issue, landing on next, squash merged by manager on successful review. manager owns dispatching workers to resolve merge conflicts. next is always ready for me to merge to main without notice." And: "manager merges the pr to next i mean, not directly with git." So do NOT consolidate or close these PRs. Retarget each to base `next`, squash-merge it there through Gitea on a passed review, and dispatch a worker for any that will not merge cleanly. `main` is only ever touched by the milestone PR from `next`, which sneak merges. Feature branches may be red; `next` and `main` must stay green. Create `next` from `main` if it does not exist here yet. Drop the `WIP: ` prefixes once retargeted.

clawbot referenced this issue

2026-09-03 15:14:15 +02:00

AGENTS.md does not document the next-branch workflow, so every agent defaults to branching off main #94

clawbot closed this issue

2026-09-03 15:14:30 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/mfer#91