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

New Issue

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

clawbot commented

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

This outranks all feature work in this repo. Do it before anything else, including the newly unblocked work on #93 and #107 .

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 N open PRs means N-1 conflict the moment the first lands — and the ordering burden falls on him. That is our job, not his.

What to do

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

Known collision: #97 removes the last DNS mocking and rewrites internal/watcher/watcher_test.go; that file has previously conflicted with lint-related changes over the goconst fixture constants. Resolve in favour of the live-DNS rewrite — the IRON RULE stands, DNS is never mocked here.

Definition of done

One next branch containing all of the above 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. Lint must run in Docker per #134 .
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.

Then

Issues #104, #105, #111 and #114 were blocked on #97 merging. Once its work is on next, they can proceed against next rather than waiting for main.

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, including the newly unblocked work on https://git.eeqj.de/sneak/dnswatcher/issues/93 and https://git.eeqj.de/sneak/dnswatcher/issues/107 .** 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 N open PRs means N-1 conflict the moment the first lands — and the ordering burden falls on him. That is our job, not his. ## What to do Fold every open PR here onto a single `next` branch, in a sensible order, resolving the conflicts **between them** yourself: - https://git.eeqj.de/sneak/dnswatcher/pulls/97 - https://git.eeqj.de/sneak/dnswatcher/pulls/112 - https://git.eeqj.de/sneak/dnswatcher/pulls/113 - https://git.eeqj.de/sneak/dnswatcher/pulls/118 - https://git.eeqj.de/sneak/dnswatcher/pulls/122 Known collision: #97 removes the last DNS mocking and rewrites `internal/watcher/watcher_test.go`; that file has previously conflicted with lint-related changes over the `goconst` fixture constants. Resolve in favour of the live-DNS rewrite — the IRON RULE stands, DNS is never mocked here. ## Definition of done - One `next` branch containing all of the above 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. Lint must run in Docker per https://git.eeqj.de/sneak/dnswatcher/issues/134 . - 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. ## Then Issues #104, #105, #111 and #114 were blocked on #97 merging. Once its work is on `next`, they can proceed against `next` rather than waiting for `main`. ## 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:43 +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:03 +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. next already exists here. 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. `next` already exists here. Drop the `WIP: ` prefixes once retargeted.

clawbot closed this issue

2026-09-03 18:16:36 +02:00

clawbot referenced this issue

2026-09-03 18:17:07 +02:00

TODO.md collides on every single PR, and its Workflow section still says to branch from main #140

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/dnswatcher#135