Repository navigation
Pin: unsloth/Qwen3.8-Flash-Next-GGUF - #1215
bong-water-water-bong merged 2 commits into
Conversation
bong-water-water-bong
left a comment
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY at 67f30c08.
Every value in the entry is the Hub's, taken independently of the tool:
pinned commit d9620119 == unsloth/Qwen3.8-Flash-Next-GGUF's current main sha (repo public, not gated)
5 of 5 files match the tree at that commit on both oid (lfs sha256) and size:
MTP/mtp-...-Q8_0.gguf 4137429120 58a47d6a...
UD-Q4_K_XL/...-00001-of-00004.gguf 10946618 acc44040...
UD-Q4_K_XL/...-00002-of-00004.gguf 49720539552 45792ae8...
UD-Q4_K_XL/...-00003-of-00004.gguf 32803030176 8c76e79d...
UD-Q4_K_XL/...-00004-of-00004.gguf 28800138432 5de8b5db...
One thing worth putting in the merge note, because it looks like a data error on first read: the values this replaces do not match the tree at the same commit either — main's 00003 says 49,376,141,504 B and the tree says 32,803,030,176 B. So this is not "a new upstream revision moved under us"; the entry was recording oids/sizes from a different revision than the commit it names, and the numbers were never checkable against the pinned tree. That is exactly what making the pin a per-file record is for, and it means the re-measured rows that quote these files should be re-read against the new sizes (the 00003/00004 split changed by ~16 GB between them, so any "bytes on disk" figure for the Q4_K_XL set moves even though the total shrinks only ~1.4 GB).
pinned moving to 2026-11-06 with no used_for change is right: the reason did not change, only the bytes.
PR Reviewer Guide 🔍(Review updated until commit 5ca3d63)Here are some key observations to aid the review process:
|
|
Persistent review updated to latest commit 5ca3d63 |
…ported, not a bump PR (#1321) `--check` called a pin "moved" when the repo's `main` moved *or* a tracked file's bytes did, so a vendor editing its README minted a bump PR. Measured on today's pins (`1 of 148 moved`): unsloth/Qwen3.8-Flash-Next-GGUF d9620119 -> 084c631a commits: "Update README.md" x3 (2026-11-07) 40 new .gguf upstream, none of them tracked by the pin all five pinned files: same lfs.oid and `unsloth/Qwen3.8-Flash-Next-GGUF` had already produced #1215 and #1257 that way. A daily PR a human has to approve is a queue item; approving pin PRs reflexively is how a `TEMPLATE CHANGED` row gets waved through, which is the one thing this watch exists for. The pin already records the **bytes** of every file (`lfs.oid` + size) independently of the commit, so a HEAD-only move changes nothing we hold. Such a repo is now `head_only`: - reported in its own section, **Head moved, no tracked file changed**, with the commit titles and the new untracked `.gguf`/`.q4nx` files — so "they re-quantised" and "they only edited the README" both stay visible; - counted in the first line apart from the moves: `0 of 148 moved, 1 head moved without a file change`; - carried in the JSON (`head_moved_no_file_change`, and `head_only: true` on the row); - exits **0** and opens **no PR**; - `--pr-body` refuses it in one wording, like the census rows: *"moved its HEAD but no file we track changed, so there is nothing to adopt and no bump PR to open"*. Measured before/after on the real pins, same minute: main: # Model pins: 1 of 148 moved -> exit 1, the workflow opens a PR branch: # Model pins: 0 of 148 moved, 1 head moved without a file change -> exit 0, bump step skipped A byte change is still a real bump, and a `404` is still a finding — both asserted in the same self-test run as the head-only case, so the fix cannot be "ignore head moves". Self-test **60 -> 75** (`ok`, 0 FAIL), `tests/workflow_shell_test.py` all pass (the new section is a `## H` heading, not `## \`repo\``, so the workflow's `moved=` count cannot pick it up), `copyright.py --check` clean. docs/model-pins.md: the exit-1 row says **bytes**, and "The daily check" explains the split with the measurement above. Follow-up to #1193/#1181 (the watch they built) — reported, not filed. Co-authored-by: bong-water-water-bong <bong-water-water-bong@1bit.gg>
The bytes we hold from
unsloth/Qwen3.8-Flash-Next-GGUFare not what it serves atd9620119— our copies predate the head. Merging this re-pins the tracked files to the bytes upstream serves now, which is a re-host, not a commit bump.MTP/mtp-Qwen3.8-Flash-Next-Q8_0.ggufcd87e5d1a4da…, upstream 4,137,429,120 B58a47d6a2163…UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-00001-of-00004.gguf4448186216b3…, upstream 10,946,618 Bacc44040f74d…UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-00002-of-00004.gguf3f342f1c1580…, upstream 49,720,539,552 B45792ae86907…UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-00003-of-00004.gguf56758f40269c…, upstream 32,803,030,176 B8c76e79d444b…UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-00004-of-00004.gguf753bda48b98b…, upstream 28,800,138,432 B5de8b5dbf894…Merging the pin does not adopt the new revision anywhere: the catalog entry, the stick image and
the scoreboard each move on their own reviewed change. Merging says this is the revision we
point at — so the template column above has to be clean first (docs/model-pins.md).
Report:
tools/pin_watch.py --check(the dailypin-watchworkflow).