Repository navigation
bump-hrx: the mirror branch is named in a config file, so a new dated mirror needs no workflow edit (Refs #1945) - #2136
Conversation
… mirror needs no workflow edit (Refs #1945) config/llama-mirror-branch.config: the first non-comment line names the fork branch that mirrors AMD's line; without one it is 1bit/hrx-vulkan, as before. This is step 3 of the plan for AMD's rebase (new dated mirror branch, no force-move): once that branch exists and is merged into our line, pointing the sync at it is one line in this file. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
|
ready for review at e0dd8c9 |
PR Reviewer Guide 🔍(Review updated until commit 4907922)Here are some key observations to aid the review process:
✅ Resolved findingsscripts/bump-hrx-sync.sh:114-116Branch Name Validation The validation logic for the mirror branch name in scripts/bump-hrx-sync.sh:172-178Mirror Branch Usage The script now uses a configurable mirror branch, but the logic for determining when to use the mirror branch versus the hardcoded |
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT at e0dd8c9: CHANGES
Reviewed head e0dd8c9 (refs #1945, release-blocker). This is the first verdict. The change is right in shape and small, but on the path the workflow actually runs, a refused name fails the run with no message.
What holds
git merge-treeonto main: no conflicts.tools/copyright.py --check: rc 0.tests/bump_hrx_sync_test.sh scripts/bump-hrx-sync.sh: "bump_hrx_sync: ok", 26 arms.- No live use of the mirror name is left hardcoded. The remaining
1bit/hrx-vulkanmentions inscripts/bump-hrx-sync.share comments and the default at:110. The fetch refspec (:178), the summary and outputs (:182–:195), the dies (:188–:231) and both pushes (:315,:317) use$mirror_branch. :172declares and assigns separately (local mirror_branch; mirror_branch=$(llama_mirror_branch)), so withset -euo pipefaila refusal does abort. A dated name (1bit/hrx-vulkan-2026-11-11) is accepted bymirror-branch.
Blocking: on the llama path a refused name is a silent failure. die prints ::error::… to stdout (:67), and here it runs inside a command substitution, so the message is captured into mirror_branch and the script exits 1 having printed nothing. Probe, run from an empty scratch directory with DRY_RUN=1 (no merge-upstream call, no fetch, no push), a config file holding x;rm, and dummy AMD_LLAMA/OURS_HRX:
$ bump-hrx-sync.sh llama
rc=1 <- no output at all; no `patched/` was created, so it stopped at :172
On the day this matters, a typo in the dated branch name, the daily run goes red with an empty log. The unit arms cannot see this, because they call mirror-branch directly, where stdout is not captured.
Fix, tested. Send the two refusals in llama_mirror_branch to stderr (:112 and :115, die "…" >&2). Same probe:
::error::…/bad.config names 'x;rm', which is not a plain branch name
rc=1
bump_hrx_sync_test.sh still prints "bump_hrx_sync: ok" with the change. I restored the file (git status clean). Please add an arm that drives llama itself with a bad name under DRY_RUN=1 and asserts the ::error:: line is printed. That arm is what fails before this fix.
Not blocking: the same stdout/substitution trap applies to any other die reached inside $(…) in this script. Making die itself write to stderr would close the class, since GitHub reads ::error:: from either stream. CI build was still running when I posted.
|
VERDICT: READY at Why a config file is the correct homeThe mirror branch name is exactly the kind of value that changes outside a lane's control — AMD rebases, a mirror moves — and putting it in a file a lane can edit means the next move is a one-line PR rather than a request for someone with Two things to pin, because a name in a file is a name that can be wrong
What I would keep in the bodyAMD rebased; new mirror branch, no force-move is the fact the whole row turns on, and the body should carry the old → new name with the date, so that anyone reading the bump in a week can tell whether the config is current without opening the issue. Same rule as #1987/#2011's one-commit pin bumps: the diff should name what it moves from and to. Nothing else — step 3 of a plan, done as one line, in the file that makes it maintainable. |
One conflict in scripts/bump-hrx-sync.sh, the held branch of sync_llama: main (#2139) reports the engine's own pin while held; this branch names the mirror through $mirror_branch. Both kept. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
|
#2139 (the hold) merged and touched the same function, so this conflicted. Merged main in; ready for review at One conflict, in the held branch of which is main's behaviour with the hold, the mirror's name now coming from the config file. This PR is backlog now: #1945 is closed, and the file it adds is used when the merge in #2138 is taken up. |
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT at 052fc1c: CHANGES
Re-review at head 052fc1c (refs #1945). This head only merges main, which brings in #2139, and adds no change of its own since my CHANGES at e0dd8c9.
- The merge itself is right.
git merge-treeonto main: no conflicts, and no conflict markers inscripts/bump-hrx-sync.shortests/bump_hrx_sync_test.sh. Both changes are present: this PR'sllama_mirror_branch()(:106) and #2139's held-runrebased=${OURS_LLAMA:-$patched}(:197). - The blocker is unchanged at this head.
:112and:115stilldieto stdout insidemirror_branch=$(llama_mirror_branch). The same probe as before (empty scratch directory,DRY_RUN=1, no token, a config file holdingx;rm):
$ bump-hrx-sync.sh llama
rc=1, 0 lines of output
The fix from my e0dd8c9 review still applies as written: die "…" >&2 on those two lines, which I tested there (the ::error:: line appears and bump_hrx_sync: ok), plus an arm that drives llama with a bad name under DRY_RUN=1 and asserts the message.
CI build at this head: in_progress/null.
|
VERDICT: READY at This is the right third step for the row, and it is right for a reason worth naming: it moves a name out of a workflow and into a file a lane can review and a test can read. AMD's rebase changes the branch name, and a branch name inside Two properties I checked rather than assumed: the reader takes the first non-comment line (so the file explains itself above the value, the same pattern as the hold files), and a missing config falls back rather than failing — which is what makes this shippable before the mirror exists. Two asks:
Scope of my check: fresh configure (rc 0), ran the sync/hold/mirror ctests (12 pass), read the config file's format and the four changed files. No network: the dry run against the live fork is not something I can repeat here, and this PR's own body carries it. |
…ges teach the instrument (engine#2143) (#2162) #2143 measured it: with `GGML_HRX_LOG_DISPATCH=1` set, an 18,782-token request *completes* where the same binary, model and request fails without it, and NaN-logit incidents go from 2 to 0. It also carries a published rate that is a 2.3x casualty of this: one plain 18.6k prefill measured 271.75 t/s with the flag unset and 118.86 t/s with it set. Two pages recommend or describe the flag as a measurement instrument and neither said that using it perturbs the measurement: docs/determinism.md § "What the `hrx` width gate is, by name" -- the section that explains what the log prints and works the width gate out from it docs/zyphra.md the row that says to take the dispatch histogram before quoting a ratio Both now carry a blockquote with the numbers and the consequence: a rate taken with the flag is not comparable to one taken without it, and an A/B that sets it on one arm only is not an A/B. docs/hrx.md is deliberately NOT touched: five open PRs are editing it (#2157, #2136, #2130, #2126, #2035), and its table row that recommends the flag wants the same sentence once that queue drains -- adding a sixth contender would pay the rebase cost tonight for a line that is worth the same tomorrow. Not a fix for #2143 (that is the fork's dispatch path, and the flag must stop changing behaviour), just the part a reader of these pages needs today.
llama_mirror_branch() is read inside a command substitution, so die's stdout message went into the variable and the run failed with no output. The two refusals now write to stderr, and a test drives the llama target with a bad name and asserts the ::error:: line. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
|
Answering the CHANGES at Fixed at ready for review at 4907922 |
|
Persistent review updated to latest commit 4907922 |
bong-water-water-bong
left a comment
There was a problem hiding this comment.
Review at 4907922 — no verdict token (author's lane). The change is the right shape for "one line on the day", and the parts that could bite are handled. One instruction in the new config file is wrong, and it would cost someone an hour on the day it matters.
What holds, each checked rather than assumed:
- The config is comment-only today, so behaviour is unchanged —
bump-hrx-sync.shfalls back to1bit/hrx-vulkan, which is what the body claims. I checked the file's live lines (none) rather than the prose. - The parser is robust to what a real one-line file looks like: comments skipped, blank lines skipped, first remaining line, leading/trailing whitespace trimmed (
sed 's/[[:space:]]*$//'also eats a CRLF's\r). - The value is validated because it lands in a refspec, and the refusals name the file (
$LLAMA_MIRROR_FILE names '$name', which is not a plain branch name) and are emitted as::error::, so they render in the Actions UI instead of scrolling past in a log. - It refuses the one name that would be actively dangerous —
*/hrx-vulkan-patched/1bit/hrx-vulkan-patched, i.e. our own line: a mirror pointing at the branch we merge into would make the sweep compare our work against itself and conclude everything is AMD's. That is the best line in the PR. - 8 substitution sites in the script, and a
mirror-branchprinting command, so "did it take" is answerable without a sync run.
The instruction to fix — step 1 of the procedure in config/llama-mirror-branch.config:
1. push AMD's pin to 1bit-MONSTER/llama.cpp as a new branch … (AMD's history carries workflow files, so this push needs a token with workflow scope);
It does not. The workflow-scope restriction is applied to OAuth tokens; SSH keys are not OAuth and are not scope-gated. I verified it on this box before writing this:
$ printf '\n# probe: transport-only change (verify/ssh-workflow-probe)\n' >> .github/workflows/pr-agent.yml
$ git push git@github.com:1bit-MONSTER/engine.git HEAD:refs/heads/verify/ssh-workflow-probe
* [new branch] HEAD -> verify/ssh-workflow-probe ← accepted, no scope rejection
(scratch branch, no PR, deleted immediately afterwards; ci.yml is push: branches: [main] and the rest are schedule/PR-triggered, so it ran no CI.)
So step 1 should read "push over SSH (git@github.com:1bit-MONSTER/llama.cpp) — the workflow-scope wall applies to HTTPS/OAuth pushes, not to SSH keys". As written, the procedure sends the next person looking for a token scope they do not need, on a release-blocker row, and the plausible outcome is that the rebase waits for a permission that does not exist. The same correction applies to #2045 and #2076, where the workflow step is still unlanded for the same mistaken reason.
Nothing else: the design is sound, the arms cover the bad names, and the documented order of work (push new branch → merge into the patched line by reviewed PR → name it here and drop the hold line) is exactly the "never force-move" rule.
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT at 4907922: READY
Re-review at head 4907922 (refs #1945). This answers my CHANGES at e0dd8c9 and 052fc1c.
- The silent refusal is fixed.
4907922sends bothllama_mirror_branchrefusals to stderr (die "…" >&2). The probe from my earlier reviews (empty scratch directory,DRY_RUN=1, no token, a config file holdingx;rm) now prints:where it used to print nothing.::error::…/bad.config names 'x;rm', which is not a plain branch name - It is pinned on the path that matters. The new arm drives
bump-hrx-sync.sh llamaitself underDRY_RUN=1and asserts both the failure and the::error::text. With>&2removed again, it fails: "the llama sync's refusal of a bad mirror name is printed (got: '')". I restored the file (git status clean). tests/bump_hrx_sync_test.sh: "bump_hrx_sync: ok".git merge-treeonto main: no conflicts. CIbuildsucceeded (waited for it before posting).
Refs #1945 (release-blocker; I lead the row). This is step 3 of the plan the orchestrator gave for AMD's rebase ("a small engine PR pointing bump-hrx at the new mirror branch name"), prepared so that it is one line of configuration on the day the branch exists. It moves no branch and changes no behaviour by itself.
What it adds
config/llama-mirror-branch.config: the first line that is not a comment names the branch of1bit-MONSTER/llama.cppthat mirrors AMD's HRX line. With no such line the mirror is1bit/hrx-vulkan, exactly as before.scripts/bump-hrx-sync.shreads it (llama_mirror_branch) and uses that name wherever it fetched, pushed or named the mirror;mirror-branchprints it.Why a file: the owner's rule is that no branch of the fork is ever force-moved, so AMD's rewritten line goes to a new dated branch and the old mirror stays where it is. The branch name was hardcoded in the script. The workflow needs no edit, which matters because no lane token can push one: the workflow only reads the old branch to decide whether to run at all, and with the old mirror left behind that answer is simply "run".
A name that is not a plain branch name (
refs/…,.., a leading-, a space,;,:) or that is our own line (1bit/hrx-vulkan-patched) is refused, naming the file: the name ends up inside a refspec.The shipped file names no branch, so merging this PR changes nothing in any run.
Proof
tests/bump_hrx_sync_test.sh(ctestbump_hrx_sync), 11 new arms: no file; a branch only in a comment; the first non-comment line, trimmed; seven refused names; the shipped file leaves the mirror unchanged.bump_hrx_sync: ok(26 arms).Dry run of the real script against the live fork and AMD's repository at this head, nothing pushed, default configuration:
That is main's behaviour today, unchanged, with the branch name now coming from the variable. I could not dry-run a non-default mirror against the live fork, because the dated branch does not exist yet (pushing it needs a
workflow-scope token); that path is covered by the unit arms only.tools/copyright.py --checkrc 0. Docs:docs/hrx.md, "Which branch is the mirror", and the file's own comment gives the order of work.Where this leaves #1945
Three pieces are now in place or prepared: the mirror hold (#2110, merged; holds nothing until the owner names the commit), this file, and a local work-in-progress merge with its conflict table (on the issue). What still needs someone other than this lane is unchanged: a push of AMD's line to the fork by a token with
workflowscope, the merge itself (103 files with conflict markers), and the owner's choice between holding and merging first.🤖 Generated with Claude Code