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

New Issue

clawbot · 2026-08-10T14:30:34+02:00

clawbot commented

2026-08-10 14:30:34 +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.

This repo is the clearest example of the problem: it currently has four open PRs with a merge order that exists only because one deletes a line another edits, and communicating that order to him is exactly the burden he is refusing to carry.

What to do

Fold every open PR here onto a single next branch, resolving the conflicts between them yourself, in this order:

That ordering is load-bearing: #40 replaces the go install of golangci-lint with a digest-pinned lint stage, deleting the very line #31 edits, so taking #40 before #31 turns a conflict into a one-hunk digest bump.

Definition of done

One next branch containing all four 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.
Every superseded PR closed with a comment saying where its work went, and its branch deleted.
Nothing lost: confirm each original PR's commits are represented in next before closing it.

Note

The containerised-lint work in #47 overlaps #40's lint stage. Land the consolidation first, then reconcile the two rather than doing both at once.

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. This repo is the clearest example of the problem: it currently has four open PRs with a merge order that exists only because one deletes a line another edits, and communicating that order to him is exactly the burden he is refusing to carry. ## What to do Fold every open PR here onto a single `next` branch, resolving the conflicts **between them** yourself, in this order: 1. https://git.eeqj.de/sneak/netwatch/pulls/35 2. https://git.eeqj.de/sneak/netwatch/pulls/40 3. https://git.eeqj.de/sneak/netwatch/pulls/31 4. https://git.eeqj.de/sneak/netwatch/pulls/38 That ordering is load-bearing: #40 replaces the `go install` of golangci-lint with a digest-pinned lint stage, deleting the very line #31 edits, so taking #40 before #31 turns a conflict into a one-hunk digest bump. ## Definition of done - One `next` branch containing all four 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. - Every superseded PR closed with a comment saying where its work went, and its branch deleted. - Nothing lost: confirm each original PR's commits are represented in `next` before closing it. ## Note The containerised-lint work in https://git.eeqj.de/sneak/netwatch/issues/47 overlaps #40's lint stage. Land the consolidation first, then reconcile the two rather than doing both at once. ## 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:46 +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:06 +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 commented

2026-08-10 15:43:54 +02:00

next created from main at fbfe1df. All five open PRs retargeted to base next: #35, #40, #31, #38, #44. All five fork from fbfe1df and merge-test clean into next as it stands, so the needs-rebase labels were about the old main shape; each will be rebased by a worker as next moves under it.

Landing order is the one already established here (#40 before #31 so the golangci pin is a one-hunk digest bump rather than a conflict), each squash-merged into next through Gitea on a passed review. #44 lands last: it fails deliberately, and the two defects it found (#42, #43) go in ahead of it.

`next` created from `main` at `fbfe1df`. All five open PRs retargeted to base `next`: https://git.eeqj.de/sneak/netwatch/pulls/35, https://git.eeqj.de/sneak/netwatch/pulls/40, https://git.eeqj.de/sneak/netwatch/pulls/31, https://git.eeqj.de/sneak/netwatch/pulls/38, https://git.eeqj.de/sneak/netwatch/pulls/44. All five fork from `fbfe1df` and merge-test clean into `next` as it stands, so the `needs-rebase` labels were about the old `main` shape; each will be rebased by a worker as `next` moves under it. Landing order is the one already established here (https://git.eeqj.de/sneak/netwatch/pulls/40 before https://git.eeqj.de/sneak/netwatch/pulls/31 so the golangci pin is a one-hunk digest bump rather than a conflict), each squash-merged into `next` through Gitea on a passed review. https://git.eeqj.de/sneak/netwatch/pulls/44 lands last: it fails deliberately, and the two defects it found (https://git.eeqj.de/sneak/netwatch/issues/42, https://git.eeqj.de/sneak/netwatch/issues/43) go in ahead of it.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/netwatch#48