Skip to content

Backlog processing strategy: volume without compromising quality #235

Description

@newhoggy

Backlog processing strategy: volume without compromising quality

Goal

Process the ~80 open issues without compromising code quality, performance, functionality, or
documentation accuracy, using the available hardware (M5 MacBook Pro Max, Mac Mini, Linux x86
with SIMD, minimal EC2 for SVE2).

State snapshot (2026-07-18)

The core insight

The risk is not fixing bugs wrong — it is fixing them at volume against a test suite that
silently under-reports (#227: 8 yq comparison tests skip silently and report green) and code
that is duplicated (#226: scalar type resolution in 5 sites; #161/#162: eval.rs vs eval_generic
divergence). Spend the first ~10% of effort on harnesses and consolidation; the remaining 90%
becomes safely parallelizable. PR #229's two-sided known-failures manifest is the model: every
future YAML fix is forced to update the conformance record, keeping docs accurate automatically.

Progress update (2026-07-19)

Phase 0 is essentially complete; Phase 1 (the safety net) is largely landed. The 2026-07-18
snapshot above is kept as the historical baseline; this section is the current state.

Phase 0 — done:

Phase 1 — safety net:

New tracking issues created this session: #244 (#192 Part 4b), #247 (CI regression guard
for the SSE2 classify/skip-width path). #231 is being fixed by PR #245.

Progress update (2026-07-25)

The 2026-07-19 section above is kept as historical baseline; this section is the current state.
Verified against the live issue tracker (gh issue list --state open cross-referenced against every
issue named below), not against the snapshot prose above.

Phases 0–2 and 5 are complete; the safety net is fully in place. Remaining work is Phase 3's two
open lanes (jq, YAML), the Phase 4 cleanups, and the Phase 6 perf/research + feature bulk.

Recommended sequencing from here: with #301 landed, the Phase 6 measurement guardrail is in place —
ADR-gate the architectural / core-structure perf issues (#70, #85, #228, #64, #56/#58) before
implementation, and measure every perf change against the new corpus; let the fleet drain the
jq/YAML lanes and #182/#185 under the now-complete guardrails.

Phase 0 — Reconcile state (one sitting)

Phase 1 — Build the safety net first

With jq/yq-as-oracle differential testing in place, every subsequent semantics fix ships with a
machine-checked proof.

Phase 2 — Consolidate before fixing duplicated code

Phase 3 — The correctness fleet (the bulk, ~35 small bugs)

Parallelize across modules, not within them — one in-flight PR per module lane to avoid
rebase storms:

Lane Issues Machine
jq #154#166 (post Phase 2) Any
CLI #175#180, #222, #167, #176#179 Any
YAML #168#174, #171#173 (post #226) Any
SIMD #231, #186, #196, #149 (BMI2 half) Per-arch (see below)
bits #187, #188, #44, #151#153 Any; large-tests on Mini

Every PR: failing repro test on main first → fix → differential test where an oracle exists →
clippy → patch coverage → conformance manifest updated where YAML behavior changes.

Phase 4 — Cleanups after their module's bug wave lands

Phase 5 — SVE2 batch (cost-minimized)

Phase 6 — Perf and research (strictly sequential benchmarks)

Machine assignment

Machine Role
M5 MacBook Interactive dev, orchestration, review; NEON bug #186; Rosetta x86 tests
Mac Mini Background lanes, large-tests, ARM benchmark box (sequential)
Linux x86 x86 SIMD bugs (#231, #149-BMI2, #193), x86 benchmarks, QEMU SVE2 (#194)
EC2 (SVE2) Single batch validation session after QEMU is green

Benchmarks are never run concurrently with anything; the benchmark machine is quiesced.
Rosetta on the M5 covers x86 correctness checks (as used to verify the #230 fix); it is
never used for x86 performance numbers.

Quality guardrails (definition of done per PR)

  1. Failing repro test on main before the fix
  2. Differential test against jq/yq oracle where applicable
  3. cargo clippy --all-targets --all-features -- -D warnings clean
  4. Patch coverage via omni-dev coverage diff
  5. Docs updated if the change touches documented behavior; every perf/space claim in docs
    backed by a fresh measurement on the named platform
  6. Conventional commit with required scope from .omni-dev/scopes.yaml
  7. Worktrees external under $HOME/wrk/work-trees/succinctly/<branch>/, one issue = one
    worktree = one PR

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentation

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions