Confidence: I am confident that having a policy on this would reduce related case-by-case discussions and allow us to make better decisions on providing flexibility. If someone wants to write an RFC and wants me to join as a co-author, I would be happy to help.
Acknowledgements: thanks to @joepie91 for feedback on this
I have more unanswered questions than answers right now…
The gist is likely to be further updated.
It is always nice to help users form realistic expectations. Right now we have various code paths with unclear level of support, or usage (or compatibility with the latest versions of everything); and no clear communication about support level/support tiers/realistic expectations.
Where and how can and should we let users know what to expect?
Platforms. Nix seems to need a Unix-like platform, with Linux and macOS clearly supported. WSL seems to be a good enough approximation of Linux to work. What are the expectations about FreeBSD? Cygwin? MSYS? OpenBSD? NetBSD?
Filesystems and filesystem layout. Do we need /-starting paths? We do need store path without spaces. Do we strictly need case-sensitivity?
Interfaces/subcommands. It is not always clear which of the approaches are recommendedand which are not.
Language features. There are language features that are not to be used in Nixpkgs, some are probably not recommended to use in any published Nix code. If we enumerate support tiers, we should probably include some remarks about that.
x86_64-linux native builds with glibc and gcc is our default platform, and probably the only truly first-tier one.
aarch64-linux native builds, and x86_64-darwin as a name for macOS with clang compiler are our second-tier platforms. They are built on Hydra and they are tested via ofBorg.
We need to classify various cross-builds, native i686-linux, armv7l-linux, Linux on less widespread architectures, musl-based builds, static builds.
What are the possible aspects of support levels for a Nixpkgs platform?
- bootstrap availability
- binary availability
- usage and testing level
- likelihood to get a previously unnoticed breakage fixed
- effort needed to get a non-trivial fix reviewed
- amount of complexity a platform-specific fix is allowed to have
Also, there are platform variants — generations for i686, instruction subsets for x86_64 (not even a linear order, because of AMD/Intel and marketing of segments of a generation but including or excluding some advanced instructions).
- What packages target which variant?
- What amount of complexity is allowed to add optional support of an older variant?
- What amount of complexity is allowed to add optional optimisations for a newer variant?
Can we describe the usage levels of packages?
Should we distinguish intended use cases? As in «this package is a Sage dependencies and nobody mentioned using it separately, so the Sage recommendation on its version will be followed».
Are there too many packages for one-by-one labels? What are the natural package groups to have a common support tier?
Do support tiers partially propagate to dependencies?
Can we distinguihs maintainer commitment level? At least two axes: «willing to help looking for fixes if something breaks … actively monitoring upstream for updates» and «willing to cede maintainership if any contributor wants it … strong ownership, careful selection of co-maintainers» (relevant for developers only)
How likely is the package to break on a dependency update, and is a nontrivial gap between breakage and a fix likely.
The amount of environment assumptions in the package (as in: NixOS OpenGL handling is assumed)
Importance and centrality of the package in terms of rebuild management. Does rebuilding this package make an update very likely to go to staging branch? Is a major fix for this package likely to go to master despite being mass-rebuild?
Generally, the defaults are built by Hydra and are probably used by someone, and the alternative versions may have a documented use-case or might just happen to be available.
Primary differences are likelyhood of bugs noticed, likelyhood of fixes happenning, complexity level of fixes.
Probably should be documented per-package by maintainers?
GRUB2 vs systemd-boot?
Hardware preferences beyond the standard Linux-kernel-driven considerations?
Display managers?
Support level for various services?
There are some escape hatches. For example, it is possible to add just a systemd unit from a file. But for a lot of escape hatches we do not tell about them too much, and only experienced users might know about the necessary tricks. Should we review the ways to work around things, and assign support tiers to the most useful or popular ones?