mirror of
https://github.com/NixOS/rfcs.git
synced 2025-12-01 14:41:12 +01:00
[RFC 0046] Platform Support Tiers (#46)
[RFC 0046] Platform Support Tiers
This commit is contained in:
Michael Raskin
Katharina Fey
parent
3165942ff7
commit
b7f4ae9583
1 changed files with 431 additions and 0 deletions
431
rfcs/0046-platform-support-tiers.md
Normal file
431
rfcs/0046-platform-support-tiers.md
Normal file
|
|
@ -0,0 +1,431 @@
|
|||
---
|
||||
feature: platform_support_tiers
|
||||
start-date: 2019-04-28
|
||||
author: Michael Raskin
|
||||
shepherd-team: Ryan Mulligan, Jonas Pfenniger, Graham Christensen, John Ericson
|
||||
shepherd-leader: John Ericson
|
||||
co-authors: Matthew Bauer
|
||||
related-issues:
|
||||
---
|
||||
|
||||
# Summary
|
||||
[summary]: #summary
|
||||
|
||||
Document the way to describe the level of support a platform can expect in
|
||||
Nixpkgs.
|
||||
|
||||
# Motivation
|
||||
[motivation]: #motivation
|
||||
|
||||
When adding a new platform, be it a new C library option, a new
|
||||
cross-compilation target configuration or a new CPU architecture, there is a
|
||||
discussion of support expectations and maintenance burden. Having a documented
|
||||
vocabulary to describe the expectations and documented precedents should make
|
||||
such discussions more efficient. Building a consensus about a standard list of
|
||||
restrictions for less-popular platform support can also streamline most
|
||||
of the decisions of this type.
|
||||
|
||||
# Detailed design
|
||||
[design]: #detailed-design
|
||||
|
||||
## Concrete actions
|
||||
|
||||
If this RFC is accepted, the following changes will happen:
|
||||
|
||||
* The definition of support tiers and a list of platforms with the
|
||||
corresponding support tiers is added as an appendix to the Nixpkgs manual. The
|
||||
list of platforms is further maintained as a part of the Nixpkgs manual. The
|
||||
platform list in the manual will be initially based on the list in the appendix
|
||||
of the present RFC.
|
||||
|
||||
* Other official documentation and marketing materials of the Nix/Nixpkgs/NixOS
|
||||
project are edited and maintained to be consistent with the platform list in
|
||||
the manual.
|
||||
|
||||
* NixOS GitHub organisation teams @NixOS/aarch64-maintainers and
|
||||
@NixOS/exotic-platform-maintainers are created.
|
||||
|
||||
* Platform support status at the Tier 4 and below is updated according to
|
||||
achievement of the requirements defined in this RFC.
|
||||
|
||||
* Discussions of platform support at the Tier 3 and above start using the
|
||||
vocubulary based on this RFC and ensure that the requirements of this RFC are
|
||||
met.
|
||||
|
||||
## Platform elements
|
||||
|
||||
* CPU architecture (possibly: subarchitecture, optional features)
|
||||
* OS ABI
|
||||
* C compiler
|
||||
* C library
|
||||
* OS kernel
|
||||
* NixOS/non-NixOS global layout, in case of Linux with glibc
|
||||
* Global linking options
|
||||
|
||||
## Questions to answer for each platform
|
||||
|
||||
* What fraction of packages are expected to work?
|
||||
* How many users there are / how much testing one can expect?
|
||||
* How much complexity is a platform-specific fix allowed to carry?
|
||||
* Is there a binary cache for the platform?
|
||||
* What platform-related builds are channel update blockers?
|
||||
* Is the platform normally tested by the tools like ofBorg? Is it possible to
|
||||
get something tested with a reasonable effort?
|
||||
* Is there expectation that updates do not break things for this platform?
|
||||
* How many developers are interested in the platform? How easy it it to get a
|
||||
non-trivial fix reviewed?
|
||||
* Is Nix supported?
|
||||
* Are native bootstrap tools available?
|
||||
|
||||
## Mutual obligations between the platform developers and the community
|
||||
|
||||
It is expected that the work necessary for supporting a platform is done by
|
||||
people using the platform, as they have both qualification and motivation for
|
||||
such work. In many cases a part or the entire build capacity will also be
|
||||
provided by the platform users. The only cost recognising platform support is
|
||||
allowed to impose on all the developers and users of Nixpkgs is the additional
|
||||
code and additional conditions for a proposed change to be considered correct.
|
||||
|
||||
The platform support tier defines how intrusive and widespread the changes
|
||||
needed to support the platform are allowed to be, and the amount of effort
|
||||
spent on avoiding the changes causing platform-specific regressions.
|
||||
|
||||
To qualify for a tier, the platform support should meet requirements on package
|
||||
coverage (how useful it is to users), and tooling (how easy it is to check the
|
||||
changes on the platform without access to the platform, and to start using the
|
||||
platform). Recognition of the lower tiers (Tier 5 and below) is based on
|
||||
a technical review of the platform support code quality and requirements. For
|
||||
higher tier an explicit decision has to be made based on the technical merits,
|
||||
future expectations, resource allocations and project priorities. As this is not
|
||||
a purely technical decision, this RFC only stipulates that a serious discussion
|
||||
occurs once any new platform meets technical requirements of a high tier.
|
||||
|
||||
It is expected that a platform in a stable situation doesn't come close to
|
||||
satisfying the technical requirements of the next higher tier, neither in terms
|
||||
of coverage nor in terms of tooling. So in a stable situation the permitted
|
||||
impact, the package coverage and the tooling for a platform correspond to the
|
||||
same tier.
|
||||
|
||||
## Main support dimensions
|
||||
|
||||
### Impact (support tier)
|
||||
|
||||
This dimension describes the permissible impact of a platform on the Nixpkgs
|
||||
repository. This includes the necessary patches as well as the handling of the
|
||||
build failures of updates in Nixpkgs.
|
||||
|
||||
### Tooling requirements
|
||||
|
||||
This dimension measures how easy it is to find out what works and what doesn't
|
||||
on the platform (in particular, without being a user of the platform).
|
||||
|
||||
### Package coverage
|
||||
|
||||
This dimension measures availability of the most important packages on the
|
||||
platform. It is intended to describe how useful is the current state of the
|
||||
platform support to the current and potential users.
|
||||
|
||||
## Support tiers
|
||||
|
||||
This section defines requirements and permitted impact for different support
|
||||
tiers.
|
||||
|
||||
### Tier 1
|
||||
|
||||
#### Impact
|
||||
|
||||
Problems on these platforms can block updates for as long as necessary to
|
||||
resolve the issue.
|
||||
|
||||
Platform-specific patches can be applied as necessary.
|
||||
|
||||
Many ordinary packages are channel-blockers on Hydra.
|
||||
|
||||
#### Tooling requirements
|
||||
|
||||
Most of packages built by Hydra, full ofBorg support.
|
||||
|
||||
#### Package coverage expectations
|
||||
|
||||
Almost everything that is not explicitly platform specific and that is not
|
||||
abandoned (in Nixpkgs) works.
|
||||
|
||||
### Tier 2
|
||||
|
||||
#### Impact
|
||||
|
||||
Updates are expected not to break the build on these platforms, problems
|
||||
should be investigated. If no solution is easily found, the problems should be
|
||||
reported to the platform maintainers with a reasonable amount of time provided
|
||||
for fixing the issue.
|
||||
|
||||
Platform-specific patches are applied as needed.
|
||||
|
||||
Some ordinary packages are channel blockers on Hydra.
|
||||
|
||||
#### Tooling requirements
|
||||
|
||||
A lot of packages built by Hydra, full ofBorg support.
|
||||
|
||||
#### Package coverage expectations
|
||||
|
||||
Most packages work, credible ambition to reach Tier 1 coverage at some point.
|
||||
|
||||
### Tier 3
|
||||
|
||||
#### Impact
|
||||
|
||||
Completely platform-specific fixes are expected to be rare and non-intrusive.
|
||||
Fixes to the compilation toolchains are expected.
|
||||
General cleanups of non-standard assumptions (e.g. «everything that is not x86
|
||||
is a kind of ARM» or «malloc(0) behaviour is a reliable indicator of other
|
||||
malloc features») useful for these platforms are welcome.
|
||||
|
||||
Updates might break builds on this platform.
|
||||
|
||||
No channel-blocking jobs on Hydra.
|
||||
|
||||
#### Tooling requirements
|
||||
|
||||
Native bootstrap tools available, cross-build toolchains in the binary cache.
|
||||
|
||||
It is recommended to provide a derivation to test the software on this platform
|
||||
(e.g. a Qemu-based derivation with all the necessary scripts).
|
||||
As it is impossible to provide a legal testing setup for a Tier-2 platform
|
||||
(macOS), this requirement is not strictly mandatory for Tier-3 tooling.
|
||||
|
||||
#### Package coverage expectations
|
||||
|
||||
Most of the popular packages work.
|
||||
|
||||
### Tier 4
|
||||
|
||||
#### Impact
|
||||
|
||||
Fixes necessary for this platforms must be either limited to compilation
|
||||
toolchains, or general cleanups of non-standard assumptions (e.g. «everything
|
||||
that is not x86 is a kind of ARM» or «malloc(0) behaviour is a reliable
|
||||
indicator of other malloc features»). These fixes must be generic: there
|
||||
should be a reasonable expectation that other exotic platforms would equally
|
||||
benefit from the exact same fix.
|
||||
|
||||
#### Tooling requirements
|
||||
|
||||
None.
|
||||
|
||||
#### Package coverage requirements
|
||||
|
||||
Some packages work.
|
||||
|
||||
### Tier 5
|
||||
|
||||
#### Impact
|
||||
|
||||
It is recommended to keep platform-specific patches to the toolchain in a
|
||||
separate package. Cleanups not necessary on any Tier-4 platforms can be
|
||||
rejected if considered too intrusive.
|
||||
|
||||
#### Tooling requirements
|
||||
|
||||
None.
|
||||
|
||||
#### Package coverage requirements
|
||||
|
||||
Platform definitions present, a small number of packages might be working.
|
||||
|
||||
### Tier 6
|
||||
|
||||
Work ongoing to provide/merge Tier 5 support
|
||||
|
||||
#### Impact
|
||||
|
||||
Platform definitions and separate platform-specific toolchain packages can be
|
||||
included.
|
||||
|
||||
### Tier 7
|
||||
|
||||
No current support, but previous support or clear path to add support
|
||||
|
||||
## Platform lifecycle
|
||||
|
||||
It is expected that Tier-5 support can be added freely, and Tier-4 support is
|
||||
added once enough packages are tested and sustained development happens.
|
||||
Tier-3 support (and higher tolerance to platform-specific fixes in
|
||||
non-toolchain packages) is generally linked to higher user interest and
|
||||
sustainability of both the platform itself and Nixpkgs development for the
|
||||
platform. Note that Tier-3 tooling requirements imply allocation of some amount
|
||||
of recurring build resources (for building and testing the toolchain).
|
||||
|
||||
Tier-2 and higher support (and expectation that platform non-users pay
|
||||
attention to the platform on updates) requires deployment of test
|
||||
infrastructure for the platform.
|
||||
|
||||
Note that from the impact point of view Tier-4 only allows the platform to be a
|
||||
motivation for generic cleanups, and further tiers require commitment of
|
||||
recurring resources. This is the reason for Tier-5 addition and Tier-4
|
||||
promotion to happen inside the scope of normal technical review by the people
|
||||
working with similar platforms; further tiers require allocation and of
|
||||
hardware resources, and procedures for coordinating such financial decisions
|
||||
are out of scope for this RFC.
|
||||
|
||||
When a platform starts falling out of use, its support tier (and permitted
|
||||
impact) is reduced once it becomes clear that the current tier requirements
|
||||
will stop being met in the near future. Platform-specific patches no longer
|
||||
permissible in the context of the new support tier can be removed at will by
|
||||
the package maintainers.
|
||||
|
||||
# Drawbacks
|
||||
[drawbacks]: #drawbacks
|
||||
|
||||
Maintaining the list of platforms (and coordinating agreement on explicit
|
||||
support expectations) takes effort, both technical and organisational.
|
||||
|
||||
# Alternatives
|
||||
[alternatives]: #alternatives
|
||||
|
||||
Do nothing; make decisions on platform support trade-offs on case-by-case
|
||||
basis without a shared framework.
|
||||
|
||||
Defining a scope for Nixpkgs platform support and dropping/separating support
|
||||
for some of the currently supported platforms.
|
||||
|
||||
Defining both requirements and impact based purely on the package sets.
|
||||
|
||||
# Unresolved questions
|
||||
[unresolved]: #unresolved-questions
|
||||
|
||||
The list of currently supported platforms might still be incomplete.
|
||||
|
||||
# Future work
|
||||
[future]: #future-work
|
||||
|
||||
Clarify what other considerations there are from the point of view of support
|
||||
expectations.
|
||||
|
||||
Describe what expectations usually appear together.
|
||||
|
||||
Support expectations for packages (and package options), NixOS modules, and
|
||||
hardware configurations could also be defined.
|
||||
|
||||
Levels of desirability for tricks that are sometimes the only way but are not
|
||||
generally encouraged could be defined. (Example: when building an FHS
|
||||
environment becomes a reasonable strategy to get something running on a NixOS
|
||||
machine?)
|
||||
|
||||
Define the expetations of maintenance for specific packages; consider the
|
||||
notion of platform-specific maintenance.
|
||||
|
||||
Define the preferences about the amount of time to wait for Tier-2 platform
|
||||
fixes in various situations, and about interim resolution in case of failure
|
||||
(keep old version on one platform, mark as broken, something else).
|
||||
|
||||
# Appendix A. Non-normative description of platforms in November 2019
|
||||
|
||||
We currently have a relatively steady state, so the tiers for each platform do
|
||||
not differ too much and we can approximate it with a single tier per platform.
|
||||
|
||||
### Tier 1
|
||||
|
||||
Developer/user base: most of the Nix developers/users
|
||||
|
||||
* `x86_64-linux`, `gcc`+`glibc`
|
||||
|
||||
### Tier 2
|
||||
|
||||
Fewer developers and users, less testing; Tier-1 tooling.
|
||||
|
||||
* `aarch64-linux`, `gcc`+`glibc`
|
||||
|
||||
A team @NixOS/aarch64-maintainers shall be created to include people who
|
||||
understand the platform and use it.
|
||||
|
||||
If there is a complicated problem on this platform when updating a package
|
||||
that was previously built succesfully on Aarch64, @NixOS/aarch64-maintainers
|
||||
team should be informed.
|
||||
|
||||
* `x86_64-darwin`, `clang`+Darwin/macOS
|
||||
|
||||
If there is a complicated problem on this platform when updating a package
|
||||
that was previously built succesfully on macOS, @NixOS/darwin-maintainers team
|
||||
should be informed.
|
||||
|
||||
### Tier 3
|
||||
|
||||
* `i686-linux`, `gcc`+`glibc` — `ofBorg` builds via `pkgsi686Linux`, binary
|
||||
cache contains `wine` dependencies
|
||||
|
||||
As an exception, pure stdenv for native builds is a channel-blocking job;
|
||||
`wine` dependencies are available in the binary cache. These extra packages are
|
||||
maintained as a part of `x86_64-linux` Wine support.
|
||||
|
||||
* `armv{6,7,8}*-linux`, `gcc`+`glibc`
|
||||
|
||||
* `armv{6,7,8}*-linux`, `gcc`+`glibc`, cross-compilation
|
||||
|
||||
* `aarch64-linux`, `gcc`+`glibc`, cross-compilation
|
||||
|
||||
* `mipsel-linux`, `gcc`+`glibc`
|
||||
|
||||
* `x86_64-linux`, `gcc`+`musl`
|
||||
|
||||
### Tier 4
|
||||
|
||||
A special team @NixOS/exotic-platform-maintainers is created and can be consulted about issues related to these platforms
|
||||
|
||||
* `aarch64-none`
|
||||
|
||||
* `avr`
|
||||
|
||||
* `arm-none`
|
||||
|
||||
* `i686-none`
|
||||
|
||||
* `x86_64-none`
|
||||
|
||||
* `powerpc-none`
|
||||
|
||||
* `powerpcle-none`
|
||||
|
||||
* `x86_64-mingw32`
|
||||
|
||||
* `i686-mingw32`
|
||||
|
||||
* `x86_64-linux`, `gcc`+`musl` — static
|
||||
|
||||
* `x86_64-linux`, `clang`+`glibc`
|
||||
|
||||
* `x86_64-linux`, `clang`+`glibc` — `llvm` linker
|
||||
|
||||
* `x86_64-linux` — Android
|
||||
|
||||
* `aarch64-linux` — Android
|
||||
|
||||
* `armv{7,8}-linux` — Android
|
||||
|
||||
### Tier 5
|
||||
|
||||
* `x86_64-linux`, `gcc`+`glibc` — static
|
||||
|
||||
* `x86_64-linux`, `gcc`+`glibc` — `llvm` linker
|
||||
|
||||
### Tier 6
|
||||
|
||||
Work ongoing to provide/merge Tier 4 support
|
||||
|
||||
* `wasm-wasi`
|
||||
|
||||
* `powerpc64le-linux`, `gcc`+`glibc`
|
||||
|
||||
### Tier 7
|
||||
|
||||
No current support, but previous support or clear path to add support
|
||||
|
||||
* `aarch64-darwin`
|
||||
|
||||
* `i686-darwin`
|
||||
|
||||
* `x86_64-freebsd`
|
||||
|
||||
* `i686-solaris`
|
||||
|
||||
* `x86_64-illumos`
|
||||
Loading…
Add table
Add a link
Reference in a new issue