docs(roadmap): merge the DuckDB compile-dominator and musl rows - #284
Merged
Conversation
Implements cycle 17's finding F. The two rows described one decision and implied that three options were interchangeable, which stopped being true when the unreachable grammars came out. Until #278 they were genuinely separate problems: the grammars contributed C++ to the musl blocker and nothing to the compile time. Excising them removed the two `scanner.cc` files and left `codelore-rca` pure C, so `libduckdb-sys` `bundled` is now the only C++-compiling dependency that builds on any target we ship -- simultaneously the slowest thing in CI and the sole remaining musl blocker. One dependency and one feature flag govern both outcomes. That changes how the options rank, which is the point of merging rather than cross-referencing: - sccache hit-rate tuning helps the build time, does nothing for musl. - `dynamic` + pre-built DuckDB helps the build time but forfeits the reason musl is wanted -- the target exists to produce a *static* binary for Alpine, distroless-static and air-gapped installs, which is exactly what dynamic linking gives up. - Build-once-and-cache is the only option that closes both, provided the cached artifact is built with a musl C++ toolchain. One piece of work then delivers the CI win and the release target together. The row now says so, so the ranking is not left to be re-derived by whoever picks it up. Verified: musl appears on one line, the table is 55 rows with no malformed cells, and nothing cross-references the removed row (the cycle-16 reports cite its old line numbers, which is the dated-audit convention and correctly left alone).
emrecdr
added a commit
that referenced
this pull request
Aug 18, 2026
…nding (#285) * docs(reports): hardening cycle 18 — the sweep run properly, and one correction rejected Anchor 19a00ec; baseline 9811bd8 (v0.28.0). Delta 2 commits (#283, #284), both consequences of cycle 17. #284 VALIDATED. The roadmap merge implements cycle 17's finding F faithfully: one row, the three options ranked rather than listed, and build-once-and-cache marked as the only one closing both outcomes. It also absorbs the correction #283 made to that same finding — the row says libduckdb-sys is the only C++-compiling dependency "that builds on any target we ship", repairing my flat claim rather than leaving the fix in a report. CORRECTIONS: two accepted, one rejected. Accepted — aho-corasick is still in Cargo.lock (pulled by globset, regex, regex-automata). Cycle 17 said petgraph and aho-corasick were "both now absent"; only petgraph left. Removing it from codelore-rca's manifest deleted an unused DIRECT dependency, not the crate from the build. #283's framing is fair: written without opening the lockfile, in the paragraph claiming credit for finding dead dependencies. Accepted — iana-time-zone-haiku also ships a scanner, so calling libduckdb-sys "the only C++-compiling dependency" was incomplete; it sits behind cfg(target_os = "haiku") and builds on no target we ship, so the finding stands. REJECTED, with evidence — "gh-pages is an orphan branch, so 'behind' does not measure anything there." The orphan fact is correct and new to me (git merge-base main gh-pages is empty). The conclusion is not: git branch -v's [behind N] never compares to main, it compares a branch to its own upstream. gh-pages tracks origin/gh-pages, and `git rev-list --count gh-pages..origin/gh-pages` is 13 — exactly what cycle 17 §6 said ("13 behind locally, which is the publishing job"), a phrasing that already encodes cycle 9's E1 lesson. Recorded as rejected rather than quietly accepted, because deferring to a correction without verifying it is the same failure as accepting a finding without verifying it. The underlying observation — that this figure invites misreading, twice now — stands. F (LOW, new) — codelore-rca declares three more dependencies it does not use: serde_json, num-traits, rayon. Zero occurrences anywhere in its src/, no aliased imports that could hide them; the same vendoring residue class as petgraph and aho-corasick. Found by finally running the sweep properly — all three crates, all dependency tables, all source roots including build.rs, with - to _ normalisation. Cycle 16's version covered two crates with a crude method and skipped the one the finding was about. Bounded before claiming, per the aho-corasick lesson: removing all three changes the build by NOTHING. serde_json is a direct dep of both lib and cli; rayon of lib; num-traits is pulled by the whole arrow stack, chrono, criterion and the num-* family. This is manifest hygiene only — the value is that a vendored crate's manifest overstates what the vendored code needs, which misleads whoever is working out what the fork still depends on. Complementary to #278's note that unused-dependency tooling would not have found the grammars: it would find these three. The classes are disjoint — unreferenced-declared (tooling catches) vs referenced-but-unreachable (reachability analysis catches) — and the project has now hit one of each. cargo-machete is the natural guard for the first. * docs(reports): land cycle 18, withdraw a wrong correction, fix its finding Two corrections in opposite directions, both settled by running a command rather than by reading text. Cycle 17's gh-pages correction is WITHDRAWN. It claimed "13 behind" was meaningless because gh-pages is an orphan branch with no common ancestor with main. The orphan fact is true and irrelevant: [behind N] never compares to main, it compares a branch to its own upstream. gh-pages tracks origin/gh-pages, `git rev-list --count gh-pages..origin/gh-pages` is 13, and `git branch -vv` prints "[origin/gh-pages: behind 13]" verbatim. The original figure was correct and standard. The correction measured gh-pages..main (807) -- a comparison the report never made -- and generalised from it. Cycle 18 section 2.3 rejected it with that evidence; the rejection is upheld and the retraction lands here. Cycle 18's own finding is CORRECTED. It listed three unused dependencies in codelore-rca. Only two are removable: serde_json + rayon removed -> cargo check --all-targets: 0 errors num-traits removed -> error[E0463]: can't find crate for `num_traits` in six language_*.rs files codelore-rca derives FromPrimitive in six generated files, and num-derive's documentation states its macros assume num_traits is a direct dependency unless the #[num_traits = "..."] helper names another path -- which this crate does not use. The derive emits bare num_traits:: paths that must resolve in this crate's own extern prelude, so a transitive copy does not help. Three claims fall with it: "all three unreferenced", the "removing all three changes the build by nothing" bound, and the tooling note's assertion that cargo-machete would find all three. It would flag num-traits as a false positive, so the recommendation now carries the qualifier that any such step must ignore num-traits and be read as a candidate list. The finding survives as two removable dependencies, and gains a better lesson than it started with: "absent from the source text" and "safe to remove" are different predicates, and only the second is checkable by building. * docs(reports): make cycle 17's header note match its withdrawn correction The header still listed the gh-pages figure among the corrections made in place. That correction is withdrawn in the same PR, so the summary now counts two surviving corrections and points at the retraction. --------- Co-authored-by: Emre <emre@valocom.nl>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements cycle 17's finding F, validated in #283.
Why the rows merge
Until #278 the two roadmap entries described genuinely separate problems: the unreachable grammars contributed C++ to the musl blocker and nothing to the compile time. Excising them removed
bca-tree-sitter-preproc's andbca-tree-sitter-ccomment'sscanner.ccand leftcodelore-rcapure C.libduckdb-sysbundledis now the only C++-compiling dependency that builds on any target we ship — simultaneously the slowest thing in CI (~6000.cppfiles, 5–7 min) and the sole remaining blocker onx86_64-unknown-linux-musl. One dependency, one feature flag, both outcomes.Why merging matters rather than cross-referencing
The old
:119row offered three options as if interchangeable. Once the rows are read together they are not:dynamic+ pre-built DuckDBBuild-once-and-cache is the only option that closes both, and it is now load-bearing for two outcomes rather than one of three ways to speed up a build. The merged row states that, so the ranking does not have to be re-derived by whoever picks the work up.
Verification
muslappears on exactly one linedocs/reports/is excluded from the doc-currency guard for exactly this reason) and correctly left alone.Docs only; no code touched.