docs(web/guides): replace nonexistent install.sh URL with working .deb/.rpm install#2604
Conversation
![wheels-bot[bot]](https://avatars.githubusercontent.com/in/3657588?s=60&v=4){kind=small}
There was a problem hiding this comment.
Wheels Bot — Reviewer A
TL;DR: Pure docs fix replacing a dead install.sh URL with working .deb/.rpm install snippets. The motivation is solid and the stable-channel instructions are correct end-to-end. Two issues need changes before merge: a bleeding-edge Aside in installing.mdx instructs users to do a simple URL substitution that silently fails (empty version variable, bad download URL), and the Linux channel-switch snippet in release-channels.mdx references wheels-be as a URL component when no install snippet in this file actually uses wheels-be as a filename — leaving users unable to act.
Correctness
1. installing.mdx line 189–191 — bleeding-edge Aside gives a broken instruction
Substitute `wheels-dev/wheels-snapshots` for `wheels-dev/wheels` in the URLs above.
The "URLs above" (lines 177–186) call /releases/latest:
WHEELS_VERSION=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels/releases/latest \
| sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p')/releases/latest only returns the latest non-pre-release published release. release-channels.mdx already states this explicitly (line 91: "The bleeding-edge channel publishes only pre-releases, so use /releases (not /releases/latest)"). If a user follows the Aside literally, the substituted API call returns nothing, WHEELS_VERSION is empty, and the subsequent curl tries to download a URL like:
https://github.com/wheels-dev/wheels-snapshots/releases/download/v/wheels__amd64.deb
which is a 404. The failure is silent in the script — curl -fsSL exits 0 on a 404 redirect page, and apt install then fails with a confusing error about a non-existent local path.
Suggested fix — replace the inline substitution prose with a self-contained snippet that mirrors the correct /releases + head -1 pattern already used in release-channels.mdx lines 92–95:
SNAP_TAG=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels-snapshots/releases \
| sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p' | head -1)
SNAP_FILENAME_VER="${SNAP_TAG//-/.}"
curl -fsSLO "https://github.com/wheels-dev/wheels-snapshots/releases/download/v${SNAP_TAG}/wheels_${SNAP_FILENAME_VER}_amd64.deb"
sudo apt install "./wheels_${SNAP_FILENAME_VER}_amd64.deb"2. release-channels.mdx lines 122–126 — Linux channel-switch snippet is comment-only and the wheels-be reference is unexplained
# apt/dnf sees the Conflicts: + Replaces: metadata and swaps the packages atomically.
# Use the install snippet from the appropriate channel above with wheels-be / wheels
# substituted in the URL — apt/dnf removes the old one as part of the transaction.The macOS and Windows snippets have concrete, copy-pasteable commands. This one has none. More importantly, none of the install snippets above (lines 83–96) contain wheels-be as a filename component. The stable snippet downloads wheels_${WHEELS_VERSION}_amd64.deb; the bleeding-edge snippet downloads wheels-${WHEELS_FILENAME_VER}.x86_64.rpm. A user who reads "substitute wheels-be in the URL" cannot figure out what to substitute where.
If the snapshots packages are actually named wheels-be_*_amd64.deb / wheels-be-*.x86_64.rpm, those names need to appear explicitly so users know what to look for. If they are still named wheels (and the channel distinction is only the source repo), the comment is misleading — the right instruction is to install from the other channel's repo URL, not to substitute a filename component.
Suggested minimum fix: Add at least one concrete example command (mirroring macOS/Windows), and clarify whether a wheels-be-named package file exists in the snapshots repo.
Docs
3. release-channels.mdx line 94 — comment misdescribes the shell substitution
WHEELS_FILENAME_VER="${WHEELS_TAG//-/.}" # GitHub Releases rewrites ~ to . in filenamesThe code replaces - with . in the variable (tag 4.0.0-snapshot.1825 → fragment 4.0.0.snapshot.1825). The comment correctly explains why the dot form exists (GitHub Releases rewrites ~ to . in asset filenames; the internal package version is 4.0.0~snapshot.1825), but a reader will wonder why the substitution is //-/. when the comment says the rewrite is ~ → .. Suggested replacement:
WHEELS_FILENAME_VER="${WHEELS_TAG//-/.}" # tag uses hyphen (4.0.0-snapshot.N); filename uses dot because GitHub Releases rewrites the internal ~snapshot.N form4. installing.mdx lines 164–172 vs. line 160 — explicit JDK step contradicts the stated package dependency
Line 160 says "The package… depends on OpenJDK 21" and installation.mdx says "apt/dnf pulls it in alongside wheels". Step 1 then asks users to install OpenJDK 21 manually before installing the package. This creates two conflicting mental models for the same operation. Either drop step 1 and let the package manager pull in the declared dependency automatically (the simpler story, consistent with installation.mdx), or add a note explaining when a manual pre-install is genuinely needed (e.g., air-gapped environments where apt cannot resolve the transitive dependency).
Commits
Single commit docs(web/guides): replace nonexistent install.sh URL with working .deb/.rpm install — valid docs type, web/guides scope, subject under 100 chars. No issues.
Wheels Bot — Reviewer B (round 1)A's review is substantively correct: all four findings are valid, the SycophancyNone detected. A gave False positivesNone detected. I re-read the cited lines for each finding:
Missed issues
The new Linux section in
The "URLs above" in WHEELS_VERSION=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels/releases/latest \
| sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p')Substituting Verdict alignmentA's ConvergenceNot aligned yet. A needs to add the |
There was a problem hiding this comment.
Wheels Bot — Reviewer A response (round 1)
B's critique is well-founded. All four original findings stand, and B correctly identified a fifth bug I missed: the installation.mdx reference guide contains the same broken bleeding-edge substitution as installing.mdx. The "substitute ... in the URLs above" prose in installation.mdx points at a /releases/latest call, which silently fails against a pre-release-only repo. Conceding that finding. Verdict stays CHANGES_REQUESTED on the same grounds, now covering both files.
Conceded points
installation.mdxbleeding-edge prose (B's missed-issue finding): The new Linux section ininstallation.mdx(added in this PR) ends with: "For the bleeding-edge channel … substitutewheels-dev/wheels-snapshotsforwheels-dev/wheelsin the URLs above." The URLs above use/releases/latest(diff lines+56–58and+62–64), which returns nothing for a pre-release-only repo. Substituting the repo name produces an emptyWHEELS_VERSIONand a malformed download URL — the same failure mode I described forinstalling.mdxfinding 1. I did not flag this in my initial review. B was correct to surface it.
Defended points
- Finding 1 (
installing.mdxAside): Confirmed. TheAsideinstructs URL substitution against/releases/latest; same root cause as the concededinstallation.mdxissue. - Finding 2 (
release-channels.mdxLinux switch snippet): Confirmed. The snippet is entirely comments with no executable command and referenceswheels-beas a URL component that does not appear in any surrounding install snippet. - Finding 3 (
release-channels.mdxline 94 comment): Confirmed. The substitution is/-/.but the comment describes the rewrite as~→.. The comment needs one more clause to bridge the gap. - Finding 4 (
installing.mdxstep 1 vs. stated package dependency): Confirmed. Asking users to manually install OpenJDK 21 contradicts both the introductory prose andinstallation.mdx's claim thatapt/dnfpulls it in automatically as a declared dependency.
Updated verdict
Still CHANGES_REQUESTED: findings 1 and 2 (now covering both installing.mdx and installation.mdx) leave users with either a silently broken install command or no command at all; those must be fixed before the docs are usable for the Linux path this PR is introducing.
…tch docs Wheels-bot's Reviewer A + Reviewer B caught five issues with the previous revision of #2604. All five address the same root tension: the docs read as if the BE channel mirrors the stable channel filename-for-filename and API-call-for-API-call, but the underlying release pipeline (release.yml hardcoding CHANNEL=stable, GitHub /releases/latest excluding pre-releases) makes the asymmetry user-visible. 1. installing.mdx Aside (bot finding 1) — the "substitute repo name in the URLs above" prose pointed at /releases/latest, which returns nothing against the pre-release-only snapshots repo. WHEELS_VERSION would be empty and the download URL would 404 silently. Replaced with two self-contained snippets (Debian/Ubuntu + Fedora/RHEL) using /releases + head -1, matching the pattern already used in release-channels.mdx. 2. release-channels.mdx Linux switch block (bot finding 2) — the previous block was comments-only with no executable command, and referenced "wheels-be" as a filename component that doesn't exist (release.yml hardcodes CHANNEL=stable, so both stable and snapshot publish a single package literally named `wheels`). Replaced with concrete stable → bleeding-edge and bleeding-edge → stable command blocks. Noted the --allow-downgrades requirement for BE → stable on apt (4.0.0 sorts below 4.0.1~snapshot.500 per dpkg). 3. release-channels.mdx comment on the version substitution (bot finding 3) — the inline comment said "GitHub Releases rewrites ~ to ." but the shell substitution is /-/. The reader had to chain three concepts themselves (tag uses hyphen → internal package version uses tilde → GitHub mangles tilde to dot at upload). Expanded the comment to spell the chain out explicitly. 4. installing.mdx step 1 (bot finding 4) — the manual `sudo apt install openjdk-21-jre-headless` step contradicted both the intro paragraph ("depends on OpenJDK 21") and installation.mdx ("apt/dnf pulls it in alongside wheels"). Dropped step 1 entirely; reworded the intro to spell out the auto-pull behavior explicitly. Step 2 (install) and step 3 (verify) renumber to 1 and 2. 5. installation.mdx BE prose (Reviewer B's missed-issue finding) — same root cause as #1, in the deeper reference doc. Same fix: replace the "substitute the repo name" prose with two self-contained BE snippets using /releases + head -1. Also added a brief BE pointer to the Linux upgrade tab, mirroring the "# or, for the bleeding-edge channel:" line in the Windows upgrade tab. Verified the BE snippet end-to-end: SNAP_TAG=$(curl ... /repos/wheels-dev/wheels-snapshots/releases | ... | head -1) → 4.0.0-snapshot.1826 → URL: .../v4.0.0-snapshot.1826/wheels_4.0.0.snapshot.1826_amd64.deb → HTTP 302 (redirect to release-assets.githubusercontent.com) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Addressed all five findings from Reviewer A + Reviewer B's missed-issue catch (commit
Verified the BE snippet end-to-end against Also added a one-line BE pointer to the Linux upgrade tab so it mirrors the Windows tab's |
There was a problem hiding this comment.
Wheels Bot — Reviewer A
TL;DR: All five issues from the previous review cycle are resolved — the installing.mdx Aside and installation.mdx bleeding-edge prose both use self-contained /releases + head -1 snippets; the release-channels.mdx Linux switch section has concrete executable commands; the version-substitution comment is expanded to walk through the full three-step chain; the contradictory manual JDK step is gone. Two gaps remain that a RHEL/Fedora user or a Windows Scoop user would hit: the Linux channel-switch section only shows apt/.deb commands (the .rpm/dnf counterparts are missing), and there is no "Windows (Scoop) — bleeding-edge → stable" snippet. Neither rises to a blocking correctness failure — the shown commands are correct and the existing snippets elsewhere in the file are close enough to adapt — so the verdict is comment.
Correctness
1. release-channels.mdx lines 127–146 — Linux switching section covers apt/deb only; no dnf/rpm commands for either direction
# Use the bleeding-edge install snippet from "Installing each channel" above
# (the wheels-dev/wheels-snapshots URLs). apt/dnf sees a newer version
# (e.g. 4.0.1~snapshot.500 sorts above the most recent stable 4.0.0) and
# upgrades in place — no uninstall step needed.
SNAP_TAG=$(...)
SNAP_FILENAME_VER="${SNAP_TAG//-/.}"
curl -fsSLO "...wheels_${SNAP_FILENAME_VER}_amd64.deb"
sudo apt install "./wheels_${SNAP_FILENAME_VER}_amd64.deb"# apt treats this as a downgrade ... so add --allow-downgrades.
# dnf handles downgrades transparently with `dnf downgrade`.
...
sudo apt install --allow-downgrades "./wheels_${WHEELS_VERSION}_amd64.deb"Both blocks name dnf in their comments but show only apt commands. The "bleeding-edge → stable" case is the harder gap: the comment tells a Fedora/RHEL user to use dnf downgrade but gives no URL to pass to it. Constructing the correct URL requires synthesising the version-resolution pattern from the "Installing each channel" section (which uses dnf install <url>, not dnf downgrade <url>) and knowing that the stable filename drops the snapshot suffix. A user following this page literally is stuck.
Suggested additions alongside each existing block:
SNAP_TAG=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels-snapshots/releases \
| sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p' | head -1)
SNAP_FILENAME_VER="${SNAP_TAG//-/.}"
sudo dnf install "https://github.com/wheels-dev/wheels-snapshots/releases/download/v${SNAP_TAG}/wheels-${SNAP_FILENAME_VER}.x86_64.rpm"WHEELS_VERSION=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels/releases/latest \
| sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p')
sudo dnf downgrade "https://github.com/wheels-dev/wheels/releases/download/v${WHEELS_VERSION}/wheels-${WHEELS_VERSION}.x86_64.rpm"2. release-channels.mdx lines 148–151 — Missing Windows (Scoop) bleeding-edge → stable snippet
scoop uninstall wheels
scoop install wheels-beThis direction exists; the reverse does not. macOS now shows both directions, Linux shows both, Scoop shows only one. The fix is symmetric to the macOS pair and trivial:
scoop uninstall wheels-be
scoop install wheelsSecurity
3. installation.mdx / installing.mdx — no integrity check on downloaded packages
The install snippets download packages over HTTPS but do not verify a detached checksum or signature before calling apt install ./…:
curl -fsSLO "https://github.com/wheels-dev/wheels/releases/download/v${WHEELS_VERSION}/wheels_${WHEELS_VERSION}_amd64.deb"
sudo apt install "./wheels_${WHEELS_VERSION}_amd64.deb"The PR description explicitly positions this as Phase 1 behavior and notes that Phase 2 adds proper GPG-signed apt/yum repos. That context is clear to someone who reads the PR, but a user hitting just the docs page sees no caveats on the trust model. A one-line note alongside the Phase 1 <Aside> — e.g. "Until the native repos are live, download integrity relies on GitHub's HTTPS transport; there is no detached signature to verify" — would set expectations correctly.
Commits
4. Both commits lack DCO Signed-off-by: trailers
CONTRIBUTING.md § DCO (merged in #2575, which appears in the ancestry of this branch) requires every commit to carry:
Signed-off-by: Peter Amiri <peter@alurium.com>
Neither 39e6689e1 nor ea694d962 has this trailer. The DCO GitHub App (https://github.com/apps/dco) is listed as a required status check in CONTRIBUTING.md; it does not appear in the current check list, which suggests the App may not be installed yet on this repo. Flagging preemptively — once the App is wired up, this will block merge. The fix (from CONTRIBUTING.md lines 65–72):
git rebase --signoff HEAD~2
git push --force-with-lease
…b/.rpm install The Linux tabs on the start-here installing guide and the upgrade flow pointed at `https://get.wheels.dev/install.sh` — a URL that was planned for the Phase 2 universal installer but doesn't exist yet. Users on Linux hit a 404 and a confusing `bash: command not found` chain. Rewrite all three install-related guides to use the .deb/.rpm packages that release.yml already produces (verified on snapshot v4.0.0-snapshot.1825). The new snippets resolve the latest version dynamically via the GitHub API, so they keep working as releases roll over. - start-here/installing.mdx: Linux install + upgrade tabs; troubleshooting no longer references the never-existed `~/.wheels/env` file. - command-line-tools/installation.mdx: split the "macOS and Linux (Homebrew)" section — Linux now has its own `.deb`/`.rpm` section with the package layout and an Aside flagging native apt/yum repos as a v4.0.x follow-up. - start-here/release-channels.mdx: replace literal `<version>` placeholders with the API-driven version resolution; extend the "Switching channels" section beyond Homebrew (Linux uses Conflicts:/Replaces: metadata, Scoop refuses dual install). Phase 2 (native apt.wheels.dev / yum.wheels.dev repositories) is planned as a follow-up — see tools/distribution-drafts/linux-packages/README.md for the full plan. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Peter Amiri <peter@alurium.com>
…tch docs Wheels-bot's Reviewer A + Reviewer B caught five issues with the previous revision of #2604. All five address the same root tension: the docs read as if the BE channel mirrors the stable channel filename-for-filename and API-call-for-API-call, but the underlying release pipeline (release.yml hardcoding CHANNEL=stable, GitHub /releases/latest excluding pre-releases) makes the asymmetry user-visible. 1. installing.mdx Aside (bot finding 1) — the "substitute repo name in the URLs above" prose pointed at /releases/latest, which returns nothing against the pre-release-only snapshots repo. WHEELS_VERSION would be empty and the download URL would 404 silently. Replaced with two self-contained snippets (Debian/Ubuntu + Fedora/RHEL) using /releases + head -1, matching the pattern already used in release-channels.mdx. 2. release-channels.mdx Linux switch block (bot finding 2) — the previous block was comments-only with no executable command, and referenced "wheels-be" as a filename component that doesn't exist (release.yml hardcodes CHANNEL=stable, so both stable and snapshot publish a single package literally named `wheels`). Replaced with concrete stable → bleeding-edge and bleeding-edge → stable command blocks. Noted the --allow-downgrades requirement for BE → stable on apt (4.0.0 sorts below 4.0.1~snapshot.500 per dpkg). 3. release-channels.mdx comment on the version substitution (bot finding 3) — the inline comment said "GitHub Releases rewrites ~ to ." but the shell substitution is /-/. The reader had to chain three concepts themselves (tag uses hyphen → internal package version uses tilde → GitHub mangles tilde to dot at upload). Expanded the comment to spell the chain out explicitly. 4. installing.mdx step 1 (bot finding 4) — the manual `sudo apt install openjdk-21-jre-headless` step contradicted both the intro paragraph ("depends on OpenJDK 21") and installation.mdx ("apt/dnf pulls it in alongside wheels"). Dropped step 1 entirely; reworded the intro to spell out the auto-pull behavior explicitly. Step 2 (install) and step 3 (verify) renumber to 1 and 2. 5. installation.mdx BE prose (Reviewer B's missed-issue finding) — same root cause as #1, in the deeper reference doc. Same fix: replace the "substitute the repo name" prose with two self-contained BE snippets using /releases + head -1. Also added a brief BE pointer to the Linux upgrade tab, mirroring the "# or, for the bleeding-edge channel:" line in the Windows upgrade tab. Verified the BE snippet end-to-end: SNAP_TAG=$(curl ... /repos/wheels-dev/wheels-snapshots/releases | ... | head -1) → 4.0.0-snapshot.1826 → URL: .../v4.0.0-snapshot.1826/wheels_4.0.0.snapshot.1826_amd64.deb → HTTP 302 (redirect to release-assets.githubusercontent.com) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Peter Amiri <peter@alurium.com>
…se paths Round-2 bot findings: 1. release-channels.mdx Switching channels — the Linux blocks named dnf in their comments but only showed apt commands, leaving Fedora/RHEL users without a usable command. Split each direction into a Debian/Ubuntu block and a Fedora/RHEL block. For the BE → stable direction, dnf gets `dnf downgrade <url>` (the rpm-native way to handle an older-version transition); apt keeps its --allow-downgrades trick. 2. release-channels.mdx Switching channels — Scoop only had stable → BE; added the symmetric bleeding-edge → stable block to match the macOS pair. 3. Trust-model documentation — Phase 1 ships .deb/.rpm without detached GPG signatures, so download integrity depends solely on GitHub's HTTPS transport. Added a `<Aside type="caution">` on both installing.mdx (the onboarding guide) and installation.mdx (the deeper reference) noting this explicitly and pointing forward to the Phase 2 signed repos at apt.wheels.dev / yum.wheels.dev. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Peter Amiri <peter@alurium.com>
bpamiri
force-pushed
the
claude/hopeful-montalcini-3c6889
branch
from
ea694d9 to
525b37e
Compare
|
Round 2 addressed (commits
Force-pushed with |
Wheels Bot — Reviewer B (round 1)A's review is accurate and evidence-backed. All four findings are confirmed against the diff. The verdict of SycophancyNone detected. A gave False positivesNone detected. I re-read the cited diff lines for each finding:
Missed issuesNone worth escalating. A caught the four substantive gaps. The version-semantics comment ("e.g. 4.0.1~snapshot.500 sorts above the most recent stable 4.0.0") is correct for the intended post-GA scenario where bleeding-edge builds toward the next minor. Verdict alignmentA's Finding 4 (DCO) cannot be addressed by the bot -- it requires the PR author to ConvergenceAligned. Joint recommendation: apply findings 1 and 2 (add the missing |
There was a problem hiding this comment.
Wheels Bot — Reviewer A
TL;DR: All five issues raised across the two previous review cycles are addressed in this revision: the broken bleeding-edge snippet in installing.mdx is replaced with self-contained snippets; installation.mdx gets the same treatment; the Linux switch section in release-channels.mdx has concrete executable commands for all four distro × direction combinations; the Scoop reverse path is added; and the trust-model <Aside type="caution"> documenting Phase 1 GPG limitations is present in both install guides. All three commits carry valid docs(web/guides): ... subjects and DCO Signed-off-by trailers. One nit remains.
Docs
1. release-channels.mdx lines 83–99 — "Installing each channel" Linux tab covers only two of four combinations
The Linux tab in the "Installing each channel" section shows two snippets:
WHEELS_VERSION=$(curl …/wheels/releases/latest …)
…
sudo apt install "./wheels_${WHEELS_VERSION}_amd64.deb"WHEELS_TAG=$(curl …/wheels-snapshots/releases …)
…
sudo dnf install "https://…/wheels-${WHEELS_FILENAME_VER}.x86_64.rpm"The pairing is diagonal: apt stable and dnf bleeding-edge. A Fedora/RHEL user looking for the stable install command, or a Debian/Ubuntu user looking for the bleeding-edge command in this section, finds neither. Both full sets of snippets exist in installing.mdx and installation.mdx, so the information is not lost — but release-channels.mdx is where a user lands when they want to compare or install a specific channel, so the gap is noticeable.
Suggested minimum fix: add the two missing snippet titles (either inline or as a labelled group), or add a note pointing to the corresponding section in installing.mdx for the missing combinations. The Switching channels section (added in round 2) already has all four distro × direction blocks, so the pattern is established — it just wasn't carried back to the Installing section.
Commits
Three commits, all conforming to commitlint:
docs(web/guides): replace nonexistent install.sh URL with working .deb/.rpm install— validdocs(web/guides): fix bot-flagged issues on Linux install/upgrade/switch docs— validdocs(web/guides): fill remaining gaps on Linux switch and Scoop reverse paths— valid
All three carry Signed-off-by: Peter Amiri <peter@alurium.com>. DCO gate is clear.
Round-3 bot finding: the "Installing each channel" Linux tab in release-channels.mdx showed only two of four distro × channel combinations — Debian/Ubuntu (stable) with apt, and Fedora/RHEL (bleeding-edge) with dnf. The diagonal pairing left a Fedora user looking for the stable rpm install or a Debian user looking for the bleeding-edge .deb install with no command they could copy out of this section. Added the two missing snippets to make the full 2×2 (apt/dnf × stable/bleeding-edge) explicit, mirroring the structure already established in the round-2 "Switching channels" section. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Peter Amiri <peter@alurium.com>
|
Round 3 addressed (commit `bf92eff7c`). Fixed A's nit on `release-channels.mdx` "Installing each channel" Linux tab: the previous revision showed a diagonal pairing (Debian/stable + Fedora/BE), leaving two combinations unaddressed. Added the two missing snippets so the section now mirrors the 2×2 structure already established in "Switching channels":
All four use the same version-resolution patterns and tag→filename translation already documented inline. Trailer on `bf92eff7c` carries `Signed-off-by: Peter Amiri peter@alurium.com`. B's round-1 comment shown alongside is the historical convergence record against the round-1 SHA (`ea694d962`) — those findings (1–4) were fully addressed in round 2; the round-3 nit is the only outstanding item, now closed. |
Wheels Bot — Reviewer B (round 1)A's review is accurate and concise. The single finding is confirmed against the diff, there is no sycophancy, and no false positives. The SycophancyNone detected. A cited specific line context before drawing any conclusion. False positivesNone detected. I re-read the relevant diff section:
Missed issuesNone detected. The Switching channels section has all four distro x direction combinations for Linux plus both directions for macOS and Scoop. Commits are valid ( Verdict alignmentA's ConvergenceAligned. A has one concrete finding and a clear suggested fix. Both A and B agree the diagonal pairing should be completed. Emitting |
|
B's review is converging against SHA `525b37ed4` (round-2 HEAD); the finding it confirms (the diagonal pairing in "Installing each channel") was already fixed in `bf92eff7c` (round 3). Verified the two missing snippet titles are present on the current HEAD: ``` Section now has all four distro × channel combinations. No additional code change needed; the next Reviewer A pass against `bf92eff7c` should confirm clean. |
There was a problem hiding this comment.
Wheels Bot — Reviewer A
TL;DR: All findings from the previous three review cycles are now resolved. This final commit fills the diagonal gap in release-channels.mdx's "Installing each channel" Linux tab that was flagged in round 3 — the full 2×2 (apt/dnf × stable/bleeding-edge) is now explicit and every snippet is functionally correct. One very minor docs asymmetry remains, but it is cosmetic only. This PR is ready to merge.
Docs
1. release-channels.mdx lines 108–113 — "Fedora / RHEL (bleeding-edge)" snippet omits the explanatory comments present in the sibling block above it
The new "Debian / Ubuntu (bleeding-edge)" block (lines 96–106) carries two helpful comments:
# The bleeding-edge channel publishes only pre-releases, so use /releases (not /releases/latest).
...
# Tag uses a SemVer hyphen (4.0.0-snapshot.N). The on-disk asset name uses a dot
# in the same slot because GitHub Releases rewrites the package's internal
# ~snapshot.N form to . at upload time. So translate hyphen → dot for the URL.The immediately following "Fedora / RHEL (bleeding-edge)" block (lines 108–113) has neither comment. A user reading the .rpm block in isolation (e.g. via a search-engine hit on the anchor) has no inline explanation for why /releases is used instead of /releases/latest, or why ${WHEELS_TAG//-/.} is needed. The two blocks are adjacent, so a sequential reader gets the context, but a tiny note like # See Debian/Ubuntu block above for an explanation of /releases and the hyphen→dot substitution would close the gap.
This is cosmetic — the snippet is functionally correct — so it does not block merge.
Prior findings — disposition
All issues raised over rounds 1–3 are resolved:
| Round | Finding | Status |
|---|---|---|
| 1 | installing.mdx bleeding-edge Aside used /releases/latest (silent fail) |
Fixed |
| 1 | release-channels.mdx Linux switch section was comment-only, no executable commands |
Fixed |
| 1 | Version-substitution comment misattributed the ~→. rewrite |
Fixed |
| 1 | Contradictory manual JDK install step | Fixed |
| 2 | Missing DCO Signed-off-by trailers |
Fixed |
| 2 | Linux dnf channel-switch snippets absent | Fixed |
| 2 | Windows (Scoop) reverse-path snippet absent | Fixed |
| 2 | Trust-model caveat (Phase 1 GPG limitation) undocumented | Fixed |
| 3 | Diagonal gap in "Installing each channel" Linux tab (only 2 of 4 combinations shown) | Fixed in this commit |
Commits
Four commits, all conforming to commitlint:
docs(web/guides): replace nonexistent install.sh URL with working .deb/.rpm install— validdocs(web/guides): fix bot-flagged issues on Linux install/upgrade/switch docs— validdocs(web/guides): fill remaining gaps on Linux switch and Scoop reverse paths— validdocs(web/guides): fill diagonal gap in Installing each channel Linux tab— valid
All four carry Signed-off-by: Peter Amiri <peter@alurium.com>. DCO gate is clear.
Wheels Bot — Address Review (round 1)Convergence at
This finding is already addressed in commit A fresh Reviewer A run will fire on the updated head ( |
Wheels Bot — Reviewer B (round 1)A's review is accurate and well-supported. The single cosmetic finding is confirmed by the diff. One additional cosmetic gap: a broken internal anchor in the upgrade section that A didn't flag. Both items are non-blocking. Aligning on approve. SycophancyNone detected. A gave APPROVED only after accounting for every prior finding in a disposition table and citing specific line context for the one remaining nit. The approval is evidence-backed. False positivesNone detected. I re-read the relevant diff lines:
Missed issues
The new upgrade prose for Linux reads:
The target Aside has The surrounding text is clear enough that a reader will still find the Aside above, so this is cosmetic and non-blocking — but it should be fixed (either correct the anchor to match the section heading it appears under, or rewrite the sentence as prose without a fragment link). Verdict alignmentA's ConvergenceAligned. The missed anchor issue is cosmetic, the same severity as A's own finding. Neither item justifies another change cycle. Joint recommendation: approve and merge. |
|
Round 4: applied the two cosmetic nits from the converged-approve review (commit `9fca5d546`):
Both reviewers had already converged on approve before this commit, so this is polish-only — no functional change. Trailer carries `Signed-off-by: Peter Amiri peter@alurium.com`. |
1 participant
Summary
https://get.wheels.dev/install.sh— a URL planned for the Phase 2 universal installer but never deployed. Users on Linux hit a 404..deband.rpmpackages on every release (release.ymllines 282-287; verified live at v4.0.0-snapshot.1825 which ships bothwheels_4.0.0.snapshot.1825_amd64.debandwheels-4.0.0.snapshot.1825.x86_64.rpm). The docs just weren't pointing at them..deb/.rpmflow with API-driven version resolution so the snippets stay correct as releases roll over.What changed
start-here/installing.mdx— Linux install + upgrade tabs now useapt install ./*.deb/dnf install <url>against the GitHub Release. Troubleshooting no longer references the never-existed~/.wheels/envfile.command-line-tools/installation.mdx— split the conflated "macOS and Linux (Homebrew)" section. Linux now has its own.deb/.rpmsection documenting the on-disk layout (/usr/bin/wheels,/opt/wheels/lucli,/opt/wheels/module/) and an<Aside>flagging the planned native apt/yum repos as a v4.0.x follow-up.start-here/release-channels.mdx— replaced literal<version>placeholders (not copy-paste runnable) with the API curl pattern. Extended "Switching channels" beyond Homebrew: Linux usesConflicts:/Replaces:metadata in the.deb/.rpm, Scoop refuses dual install.Why this is fine without Phase 2
Phase 2 (
apt.wheels.dev/yum.wheels.devnative repos served from Cloudflare Pages) is fully scoped intools/distribution-drafts/linux-packages/README.md— needs a GPG signing key, two new Cloudflare Pages repos underwheels-dev/, and a metadata-generator workflow. That's worth its own PR (and its own decision about key custody). This PR ships the Phase 1 install story — which has worked end-to-end on Linux sincerelease.ymlline 287 landed — and stops the docs from sending users to a dead URL.I'll file the Phase 2 work as a separate
v4.0.xfollow-up issue.Test plan
installing.mdxLinux tab in the preview build — confirm the three code blocks (Debian/Ubuntu install, Fedora/RHEL install, the bleeding-edge Aside) render and explain themselveswheels-dev/wheels-snapshots(substituted per the bleeding-edge Aside) — confirmwheels --versionreports a real versionwheels-dev/wheelsURL to confirm it resolves (currently 404s pre-GA becausewheels-dev/wheels's latest release isv3.0.0+50, which predates the linux packaging — first stable.deb/.rpmwill appear onv4.0.0)release-channels.mdxandcommand-line-tools/installation.mdxLinux sections agree on the install URL pattern🤖 Generated with Claude Code