These disagree. Once 1.0 is tagged the module path is effectively permanent:
changing it later is a breaking change for every importer and requires a
major-version bump under Go's import compatibility rule.
Options
A. sneak.berlin/go/mfer (recommended). Matches the repo policy — "Go
module root: sneak.berlin/go/<name>" — and matches what go.mod already
says, so no code changes beyond the proto. It is a vanity path, which
decouples the import path from where the code is hosted; the repo can move
without breaking importers. Requires that sneak.berlin/go/mfer serve a go-import meta tag, which needs to be verified as actually working before
the tag.
B. git.eeqj.de/sneak/mfer. Matches where the code actually lives and
needs no vanity-import hosting. But it contradicts the stated policy, and it
welds the import path to the current Gitea instance.
The proto's current value is a third thing again — git.eeqj.de/sneak/mfer/mfer
— which is neither of the above as a module root.
Recommendation
Option A. It is what policy mandates and what go.mod already declares; the
proto is simply wrong and should be corrected to match. The one real risk is
the vanity redirect not being served — that is worth verifying now rather
than discovering it at tag time.
Definition of done, once answered
go.mod and mfer/mf.protogo_package agree.
mfer/mf.pb.go is regenerated from the corrected proto and committed.
If option A: go install sneak.berlin/go/mfer/cmd/mfer@latest is verified
to actually resolve from a clean module cache. If it does not, the vanity
redirect must be fixed before 1.0, and that becomes a blocking sub-task.
All import paths in the repo are consistent.
README install instructions use the decided path (#75).
make check passes and docker build . succeeds.
Please answer inline and reassign to clawbot to implement.
Owner decision required. Blocks the 1.0 tag and the README install
instructions (#75).
## The conflict
- `go.mod:1` — `module sneak.berlin/go/mfer`
- `mfer/mf.proto:3` — `option go_package = "git.eeqj.de/sneak/mfer/mfer";`
These disagree. Once 1.0 is tagged the module path is effectively permanent:
changing it later is a breaking change for every importer and requires a
major-version bump under Go's import compatibility rule.
## Options
**A. `sneak.berlin/go/mfer` (recommended).** Matches the repo policy — "Go
module root: `sneak.berlin/go/<name>`" — and matches what `go.mod` already
says, so no code changes beyond the proto. It is a vanity path, which
decouples the import path from where the code is hosted; the repo can move
without breaking importers. Requires that `sneak.berlin/go/mfer` serve a
`go-import` meta tag, which needs to be verified as actually working before
the tag.
**B. `git.eeqj.de/sneak/mfer`.** Matches where the code actually lives and
needs no vanity-import hosting. But it contradicts the stated policy, and it
welds the import path to the current Gitea instance.
The proto's current value is a third thing again — `git.eeqj.de/sneak/mfer/mfer`
— which is neither of the above as a module root.
## Recommendation
Option A. It is what policy mandates and what `go.mod` already declares; the
proto is simply wrong and should be corrected to match. The one real risk is
the vanity redirect not being served — that is worth verifying now rather
than discovering it at tag time.
## Definition of done, once answered
- `go.mod` and `mfer/mf.proto` `go_package` agree.
- `mfer/mf.pb.go` is regenerated from the corrected proto and committed.
- If option A: `go install sneak.berlin/go/mfer/cmd/mfer@latest` is verified
to actually resolve from a clean module cache. If it does not, the vanity
redirect must be fixed before 1.0, and that becomes a blocking sub-task.
- All import paths in the repo are consistent.
- README install instructions use the decided path (#75).
- `make check` passes and `docker build .` succeeds.
Please answer inline and reassign to `clawbot` to implement.
clawbot
added this to the 1.0.0 milestone 2026-08-09 03:43:25 +02:00
sneak
was assigned by clawbot2026-08-09 03:43:25 +02:00
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.
Owner decision required. Blocks the 1.0 tag and the README install
instructions (#75).
The conflict
go.mod:1—module sneak.berlin/go/mfermfer/mf.proto:3—option go_package = "git.eeqj.de/sneak/mfer/mfer";These disagree. Once 1.0 is tagged the module path is effectively permanent:
changing it later is a breaking change for every importer and requires a
major-version bump under Go's import compatibility rule.
Options
A.
sneak.berlin/go/mfer(recommended). Matches the repo policy — "Gomodule root:
sneak.berlin/go/<name>" — and matches whatgo.modalreadysays, so no code changes beyond the proto. It is a vanity path, which
decouples the import path from where the code is hosted; the repo can move
without breaking importers. Requires that
sneak.berlin/go/mferserve ago-importmeta tag, which needs to be verified as actually working beforethe tag.
B.
git.eeqj.de/sneak/mfer. Matches where the code actually lives andneeds no vanity-import hosting. But it contradicts the stated policy, and it
welds the import path to the current Gitea instance.
The proto's current value is a third thing again —
git.eeqj.de/sneak/mfer/mfer— which is neither of the above as a module root.
Recommendation
Option A. It is what policy mandates and what
go.modalready declares; theproto is simply wrong and should be corrected to match. The one real risk is
the vanity redirect not being served — that is worth verifying now rather
than discovering it at tag time.
Definition of done, once answered
go.modandmfer/mf.protogo_packageagree.mfer/mf.pb.gois regenerated from the corrected proto and committed.go install sneak.berlin/go/mfer/cmd/mfer@latestis verifiedto actually resolve from a clean module cache. If it does not, the vanity
redirect must be fixed before 1.0, and that becomes a blocking sub-task.
make checkpasses anddocker build .succeeds.Please answer inline and reassign to
clawbotto implement.