Strategic question: decide package-manager ownership after v1.0

[jaharris87]

Parent umbrella: #348

Checklist ID: V1-NB-02

Framing question

After v1.0, should fTimer continue treating Spack and EasyBuild as readiness guidance only, or should the project accept ownership of upstream/site package-manager recipes?

Why this matters

Package-manager availability is a strong user-facing claim. docs/package-manager-readiness.md currently records a readiness spike, not maintained recipes or direct Spack/EasyBuild execution. v1.0 can ship without package-manager ownership, but the boundary should stay explicit.

Pressure from the current state

• README.md lists package-manager installs as experimental/deferred.
• docs/release-evidence.md says Spack/EasyBuild readiness is preliminary out-of-tree recipe guidance, not direct package-manager execution or maintained package-manager ownership.
• docs/package-manager-readiness.md includes prototype snippets with TODO placeholders and states that spack and eb were not available during validation.
• Completed Spike Spack and EasyBuild readiness without taking ownership of packaging #311 intentionally avoided taking ownership of packaging.

Options or tensions

• Keep the v1.0 stance: package-manager readiness guidance only.
• Contribute an upstream Spack recipe after a release tarball/checksum exists, without committing in-repo recipe ownership.
• Accept maintained packaging as a post-v1.0 support surface, with CI or external validation requirements.

Desired decision output

A post-v1.0 packaging ownership decision that either keeps the current readiness-only stance or opens concrete implementation issues for package-manager recipe ownership and validation.

Scope boundaries

In scope:

• Decide post-v1.0 package-manager ownership direction.
• Define required validation for any future package-manager claim.
• Keep docs clear that current prototypes are not copy-paste-ready maintained recipes unless ownership changes.

Out of scope:

• Blocking v1.0.
• Adding recipes in this issue.
• Broadening compiler/MPI/OpenMP support beyond release evidence.

Acceptance criteria

• Maintainer decides whether package-manager ownership remains out of scope for v1.0 and immediate 1.x work.
• If readiness-only remains the policy, docs keep docs/package-manager-readiness.md caveats and v1.0 release notes avoid package-manager availability claims.
• If ownership is accepted, follow-up issues define recipe ownership, validation environment, checksums, variants, installed-consumer sanity checks, and maintenance expectations.
• Any future packaging work preserves compiler/toolchain/feature-mode-specific .mod artifact caveats.

Validation required

No v1.0 validation required while this remains non-blocking readiness guidance.

If future package-manager ownership is accepted, validation should include real Spack/EasyBuild execution plus downstream find_package(fTimer CONFIG REQUIRED) consumer checks for each claimed variant.

Release-blocking status

Does not block v1.0 unless maintainers decide v1.0 must claim package-manager availability.

Dependencies

• Should stay aligned with the v1.0 release claims refresh issue.
• Related to completed Spike Spack and EasyBuild readiness without taking ownership of packaging #311.

Suggested review roles or PR labels

• codex-adoptability-review
• codex-build-portability-review
• codex-docs-contract-review

Related context

• Release: v1.0 readiness checklist #348
• completed Spike Spack and EasyBuild readiness without taking ownership of packaging #311
• README.md
• docs/package-manager-readiness.md
• docs/release-evidence.md
• docs/installed-api.md
• tests/check_installed_package_consumer.cmake