armin/xtc
1
0
Fork 0
forked from hanez/xtc
Code Pull requests Activity

Phase 30: complete configurable installation and release qualification

Browse source
This commit is contained in:
Johannes Findeisen 2026-10-27 17:13:09 +01:00
commit 90eac33a71
18 changed files with 399 additions and 59 deletions
Download patch file Download diff file Expand all files Collapse all files

29
docs/MAINTENANCE.md
View file

@ -53,3 +53,32 @@ an unsupported source file during failed Open. Keep the original when diagnosing
post-publication sync errors. Native descriptor ABI compatibility is distinct from
project format and is documented in NATIVE_API.md; opaque DSP state is not promised.
No public stability guarantee or support SLA is implied by development version 0.1.0.
## Phase 30 support and triage record
Verified compilers are GCC/G++ 16.2.1 and Clang/Clang++ 23.1.3 on x86_64 Linux;
these are tested versions, not a promise that arbitrary older/newer versions work.
The code requires C99 plus GCC/Clang lock-free atomics, C++17 for the GUI, FLTK
1.4 and POSIX/glibc APIs. JACK (including PipeWire's JACK compatibility) is the
only live backend. Native Windows/macOS, other architectures and direct ALSA
backends are not qualified. Core builds can disable JACK, FLTK and LADSPA.
See BUILD.md and LICENSES.md for dependency roles and versions.
Release qualification adds `test-install-layout`, installed example inspection,
all performance report resources, source checksum verification and the current
RELEASE_NOTES.md. Retain the original graph benchmark alert in release records;
a successful compile does not clear timing qualification gaps.
File reproducible bugs with the repository maintainers using the source commit
and archive SHA-256, `xtc-check --version`/`--diagnose`, distro/kernel and toolchain,
exact commands or GUI steps, expected versus observed behavior and frequency.
Reduce to a redistributable project and state whether it reproduces without
external plugins and with the offline/core tools. Include relevant stderr and
sanitizer traces; preserve original recovery files before experimenting.
Maintainers should first confirm version/features and reproduce in an isolated
build. Prioritize data loss/security/memory/thread defects, then crashes and
callback/deadline failures, then functional bugs and UI issues. Record severity,
reproduction conditions, affected versions, regression test and verification
command with the fix. Route timing-only alerts through matching-host reports and
repeat measurements; do not treat sanitized timings as realtime evidence.