Roadmap#
This page records the direction for kdevops-ng. It is a living list of intended work grouped by theme, not a set of dated commitments; see Overview for the current project status. Each card carries a status, planned, research, or staging, and an entry that extends an existing foundation names it.
Documentation and presentation#
planned
Add “built with” badges for the three core components, Nix, systemd, and Windmill, to the landing page or footer. Built With Nix supplies the Nix badge; the others need making.
planned
Adopt sphinx-tags so pages can be tagged by area (filesystems, memory, observability) with generated tag-index pages for filtering.
planned
Author a D2 diagram of how Windmill, systemd, and Nix fit together, and link Windmill’s own architecture page for the internals.
planned
Document deploying workers across hosts and using worker tags to route a flow to specific hardware. Extends the worker model in Nix.
staging
Explain how a Build identity keys /nix/store, on one host and
across peers. Documents the mechanism behind ADR 0002 and the build
Store. A draft is staged in Build the Linux kernel (the “Build
identity and reuse” section); review it there.
Usability#
planned
Make flows and scripts zero-config on the common path and gate the rest behind “Advanced options”. A kernel build should take a ref and a series and infer the rest (checkout, push refs, targets, configuration). The bringup form is the first target: gate its kernel, QEMU and NixOS-closure knobs behind an Advanced mode with sane defaults, which then makes room to embed the test step so one flow builds, boots and tests a kernel. Extends the “curated forms, not empty boxes” principle.
Cloud and infrastructure#
Build identity and artifact storage#
research
Today kdevops archives results in kdevops-results-archive, a git
repository of *.xz tarballs stored with git LFS so a user fetches
only the results they want. It rotates on epochs (the old repository is
renamed and a fresh one started) to bound git size and keep the public
kdevops.org dashboard, generated from the archive, fast; it also ships
compare-results-fstests.py to diff two runs for regressions and fixes.
The question is whether to content-address results in the Nix store,
keyed by their Build identity the way builds are, and distribute
that store over git with the git-backed Nix store approach, reusing
the epoch rotation to work around git’s storage limits. Open: whether it
beats git-LFS tarballs, and how it feeds the per-run results summary a
kdevops-ng user gets in Windmill (the fstests report verdict, not the
public kdevops.org dashboard) and the compare tooling.
research
A follow-up to result archival: once results are content-addressed in the Nix store by build identity, a report becomes a query over stored results rather than a fresh run. Pick any archived results (A, B, C, D), each a kernel tested under a given profile, and regenerate a comparison on demand: an A/B regression-and-fix diff, or the evolution across vanilla releases (7.0, 7.1, and so on) plotted over time.
Because each result is stored and addressed independently, a baseline and a development run need not happen together or in parallel. A vanilla baseline tested once is reused months later against a freshly archived result, so a baseline that already exists for the profile a user needs is never re-run. Git distributes the result store; Windmill steps consume it through Nix to assemble the report.
Test coverage#
These migrate proven coverage from kdevops into the flow model.
planned
Port blktests, mmtests, and kselftest groups (xarray, maple tree, modules, and others).
planned
Add btrfs, ext4, tmpfs, and other filesystem types alongside XFS.
planned
Port the benchmarking workflows: sysbench against MySQL and PostgreSQL, the fio-based tests, and others.
Developer workflows#
planned
Add a flow that drives git bisect to track a regression down to the
commit that introduced it.
Observability and metrics#
planned
Port guest monitoring for both post-run analysis (recorded) and live streaming during a run.
planned
Capture live-stream metrics in a Grafana-ready form: generic system metrics (journald guest logs, CPU, RAM); storage metrics (blktrace, blkalgn histograms); memory metrics (heatmaps, buddy-allocator status); and flamegraphs.