From ffdb91dfa1ee405a7c46829a835641896ef1628b Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Sun, 28 Apr 2019 14:07:16 +0200
Subject: [PATCH 01/21] An RFC on platform support tiers

---
 rfcs/0046-platform-support-tiers.md | 112 ++++++++++++++++++++++++++++
 1 file changed, 112 insertions(+)
 create mode 100644 rfcs/0046-platform-support-tiers.md

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
new file mode 100644
index 000000000..c8a0fd55d
--- /dev/null
+++ b/rfcs/0046-platform-support-tiers.md
@@ -0,0 +1,112 @@
+---
+feature: platform_support_tiers
+start-date: 2019-04-28
+author: Michael Raskin
+co-authors:
+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.
+
+# Detailed design
+[design]: #detailed-design
+
+## Platform elements
+
+* CPU architecture (possibly: subarchitecture, optional features)
+* OS kernel
+* C compiler
+* C library
+* NixOS/non-NixOS global layout, in case of Linux with glibc
+* Global linking options
+
+## Questions to answer for each platform
+
+* What fraction of packages is 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?
+* Is the platform normally tested by the tools like ofBorg? Is it possible to
+  get something tested with 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?
+
+## Platforms
+
+* `x86_64-linux`, native builds with `gcc` and `glibc`. Status: default
+  platform, the only truly first-tier platform. All packages not specifically
+  defined in terms of OS-specific or CPU-specific tooling for other platforms
+  are expected to work if they work anywhere.
+
+* `aarch64-linux`, native builds with `gcc` and `glibc`. `x86_64-darwin` as a
+  name for macOS with `clang` compiler. Status: second-tier platforms. Many
+  packages are supposed to work, the main Hydra puts a lot of binary packages
+  into the binary cache, there is tooling support to check builds on these
+  platforms and some level of effort is expected to be spent on investigating
+  new failures after update.
+
+* `i686-linux`, `armv7l-linux`, `x86_64-linux` with `musl`, static builds.
+  Status: cross-compilation targets in different meanings of these words. No
+  binary cache available, checking a cross-build via ofBorg is possible but
+  complicated, no expectations on upgrade. Fixes not necessary on upper-tier
+  platforms are expected to be either localised inside `stdenv` dependencies
+  and other compilers/build tools, or to be general cleanups that just happen
+  to be optional on upper-tier platforms.
+
+## Adding a new platform
+
+A proposal to add a new platform should justify the level of platform-specific
+fixes to be tolerated.
+
+Before adding an expectation that platform non-users pay attention whether
+upgrades break a lower-tier platform, support for testing on this platform
+must be available.
+
+# 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.
+
+# Unresolved questions
+[unresolved]: #unresolved-questions
+
+The list of currently supported platforms is 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?)

From fac98e8621639d60f0fb3c5709598048445a44c9 Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Sun, 28 Apr 2019 17:54:32 +0200
Subject: [PATCH 02/21] Add a lower embdedded tier

---
 rfcs/0046-platform-support-tiers.md | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index c8a0fd55d..95b01186c 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -69,10 +69,19 @@ such discussions more efficient.
   and other compilers/build tools, or to be general cleanups that just happen
   to be optional on upper-tier platforms.
 
+* Embedded systems like `arm-embedded`, `armhf-embedded` or even `avr`.
+  Status: only cross-compilation targets, no tooling support, no expectations
+  of attention from non-users. Platform-specific fixes are expected to only
+  touch immediate compiler toolchain.
+
 ## Adding a new platform
 
-A proposal to add a new platform should justify the level of platform-specific
-fixes to be tolerated.
+It is expected that embedded-level support (platform definition, basic support
+for the target, maybe a toolchain in the binary cache) can added as long as
+the support code works and is contained in the expected places. If the
+platform users want to set higher expectations, a motivation should be
+provided. User interest, platform perspectives and development effort
+commitment are usually taken into account.
 
 Before adding an expectation that platform non-users pay attention whether
 upgrades break a lower-tier platform, support for testing on this platform

From 54c4a0cac39f1dace704423d74dc9f36a1fe48fa Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Tue, 30 Apr 2019 20:36:33 +0200
Subject: [PATCH 03/21] Edits, mostly to incorporate advice by Matthew Bauer

---
 rfcs/0046-platform-support-tiers.md | 165 ++++++++++++++++++++++------
 1 file changed, 131 insertions(+), 34 deletions(-)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index 95b01186c..2dc32b89f 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -2,7 +2,7 @@
 feature: platform_support_tiers
 start-date: 2019-04-28
 author: Michael Raskin
-co-authors:
+co-authors: Matthew Bauer
 related-issues:
 ---
 
@@ -49,43 +49,140 @@ such discussions more efficient.
 
 ## Platforms
 
-* `x86_64-linux`, native builds with `gcc` and `glibc`. Status: default
-  platform, the only truly first-tier platform. All packages not specifically
-  defined in terms of OS-specific or CPU-specific tooling for other platforms
-  are expected to work if they work anywhere.
-
-* `aarch64-linux`, native builds with `gcc` and `glibc`. `x86_64-darwin` as a
-  name for macOS with `clang` compiler. Status: second-tier platforms. Many
-  packages are supposed to work, the main Hydra puts a lot of binary packages
-  into the binary cache, there is tooling support to check builds on these
-  platforms and some level of effort is expected to be spent on investigating
-  new failures after update.
-
-* `i686-linux`, `armv7l-linux`, `x86_64-linux` with `musl`, static builds.
-  Status: cross-compilation targets in different meanings of these words. No
-  binary cache available, checking a cross-build via ofBorg is possible but
-  complicated, no expectations on upgrade. Fixes not necessary on upper-tier
-  platforms are expected to be either localised inside `stdenv` dependencies
-  and other compilers/build tools, or to be general cleanups that just happen
-  to be optional on upper-tier platforms.
-
-* Embedded systems like `arm-embedded`, `armhf-embedded` or even `avr`.
-  Status: only cross-compilation targets, no tooling support, no expectations
-  of attention from non-users. Platform-specific fixes are expected to only
-  touch immediate compiler toolchain.
+### Tier 1
+
+Aims: all packages should work (unless they don't make sense)
+
+A platform-specific fix is expected to be applied in `master`
+
+Support: good binary cache coverage, full support in tooling
+
+Developer/user base: most of the Nix developers/users
+
+* `x86_64-linux`, `gcc`+`glibc`
+
+### Tier 1.5
+
+Same aims and tooling support
+
+Fewer developers and users, less testing — significantly more broken packages
+
+* `aarch64-linux`, `gcc`+`glibc`
+
+* `x86_64-darwin`, `clang`+Darwin/macOS
+
+### Tier 2-ε
+
+Aims: most of the popular packages work
+
+Platform-specific things for arbitrary packages should not be too complicated
+
+Support: native bootstrap tools are available, cross-build toolchains in the
+binary cache, partial tooling support
+
+Package updates might break build on the platforms of this tier and lower
+
+* `i686-linux`, `gcc`+`glibc` — `ofBorg` builds via `pkgsi686Linux`, binary
+  cache contains `wine` dependencies
+
+### Tier 2
+
+Aims: most of the popular packages work
+
+Support: native bootstrap tools are available, cross-build toolchains in the
+binary cache
+
+* `armv{6,7,8}*-linux`, `gcc`+`glibc`
+
+* `mipsel-linux`, `gcc`+`glibc`
+
+* `x86_64-linux`, `gcc`+`musl`
+
+* `x86_64-linux`, `clang`+`glibc`
+
+### Tier 3
+
+Aims: some packages are expected to work
+
+Platform-specific fixes limited to general cleanups of non-standard
+assumptions in the upstream code and basic toolchain fixes
+
+* `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` — `llvm` linker
+
+* `x86_64-linux` — Android
+
+* `aarch64-linux` — Android
+
+* `armv{7,8}-linux` — Android
+
+### Tier 4
+
+Aims: none
+
+Support: none or accidental
+
+Platform definitions present
+
+A small amount of packages seems to work, maybe by luck
+
+* `x86_64-linux`, `gcc`+`glibc` — static
+
+* `x86_64-linux`, `gcc`+`glibc` — `llvm` linker
+
+### Tier 4.5
+
+Work ongoing to provide/merge Tier 4 support
+
+* `wasm-wasi`
+
+* `powerpc64le-linux`, `gcc`+`glibc`
+
+### Tier 5
+
+Aims: none
+
+Support: none
+
+No current support, but previous support of clear path to add support
+
+* `aarch64-darwin`
+
+* `i686-darwin`
+
+* `x86_64-freebsd`
 
 ## Adding a new platform
 
-It is expected that embedded-level support (platform definition, basic support
-for the target, maybe a toolchain in the binary cache) can added as long as
-the support code works and is contained in the expected places. If the
-platform users want to set higher expectations, a motivation should be
-provided. User interest, platform perspectives and development effort
-commitment are usually taken into account.
+It is expected that Tier-4 support can be added freely, and Tier-3 support is
+added once enough packages are tested and sustained development happens.
+Tier-2 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.
 
-Before adding an expectation that platform non-users pay attention whether
-upgrades break a lower-tier platform, support for testing on this platform
-must be available.
+Support above Tier-2 (and expectation that platform non-users pay attention to
+the platform support on updates) requires deployment of test infrastructure
+for the platform.
 
 # Drawbacks
 [drawbacks]: #drawbacks

From 11bfe1767089a7f69f75a3b3ba3fa109735aa2ae Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Mon, 6 May 2019 14:10:55 +0200
Subject: [PATCH 04/21] Mention channel updates

---
 rfcs/0046-platform-support-tiers.md | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index 2dc32b89f..514e30aeb 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -39,6 +39,7 @@ such discussions more efficient.
 * 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 reasonable effort?
 * Is there expectation that updates do not break things for this platform?
@@ -57,13 +58,16 @@ A platform-specific fix is expected to be applied in `master`
 
 Support: good binary cache coverage, full support in tooling
 
+A platform in this tier has a set of build jobs that block a channel update in
+case of failure.
+
 Developer/user base: most of the Nix developers/users
 
 * `x86_64-linux`, `gcc`+`glibc`
 
 ### Tier 1.5
 
-Same aims and tooling support
+Same aims and tooling support, there are channel blocking jobs
 
 Fewer developers and users, less testing — significantly more broken packages
 
@@ -80,6 +84,8 @@ Platform-specific things for arbitrary packages should not be too complicated
 Support: native bootstrap tools are available, cross-build toolchains in the
 binary cache, partial tooling support
 
+Native stdenv is a channel-blocking job
+
 Package updates might break build on the platforms of this tier and lower
 
 * `i686-linux`, `gcc`+`glibc` — `ofBorg` builds via `pkgsi686Linux`, binary
@@ -92,6 +98,8 @@ Aims: most of the popular packages work
 Support: native bootstrap tools are available, cross-build toolchains in the
 binary cache
 
+This tier and lower doesn't affect channel updates
+
 * `armv{6,7,8}*-linux`, `gcc`+`glibc`
 
 * `mipsel-linux`, `gcc`+`glibc`

From b597b2b79abb19be0d49dc46abfb732bd8a5e87b Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Mon, 6 May 2019 14:14:53 +0200
Subject: [PATCH 05/21] Move clang-on-Linux down

---
 rfcs/0046-platform-support-tiers.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index 514e30aeb..c2e8a0db5 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -106,8 +106,6 @@ This tier and lower doesn't affect channel updates
 
 * `x86_64-linux`, `gcc`+`musl`
 
-* `x86_64-linux`, `clang`+`glibc`
-
 ### Tier 3
 
 Aims: some packages are expected to work
@@ -135,6 +133,8 @@ assumptions in the upstream code and basic toolchain fixes
 
 * `x86_64-linux`, `gcc`+`musl` — static
 
+* `x86_64-linux`, `clang`+`glibc`
+
 * `x86_64-linux`, `clang`+`glibc` — `llvm` linker
 
 * `x86_64-linux` — Android

From 45da8300e1e2b5ac3ecee8b11f3276bc1ecf7b66 Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Mon, 6 May 2019 14:20:12 +0200
Subject: [PATCH 06/21] Mention platform-specific teams for Tier-1.5 platforms

---
 rfcs/0046-platform-support-tiers.md | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index c2e8a0db5..2b2bfd0d3 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -71,10 +71,25 @@ Same aims and tooling support, there are channel blocking jobs
 
 Fewer developers and users, less testing — significantly more broken packages
 
+If a package update breaks a previously working package on that platform,
+update author should check if some easy fix follows from the build logs or is
+mentioned in the upstream bugtracker.
+
 * `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 macOS, @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 2-ε
 
 Aims: most of the popular packages work

From 01326f3ce8781d69de5fec142bdc52aed65ed198 Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Sat, 11 May 2019 08:57:51 +0200
Subject: [PATCH 07/21] Reword the stdenv mention for i686-linux

---
 rfcs/0046-platform-support-tiers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index 2b2bfd0d3..dc5cbe46d 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -99,7 +99,7 @@ Platform-specific things for arbitrary packages should not be too complicated
 Support: native bootstrap tools are available, cross-build toolchains in the
 binary cache, partial tooling support
 
-Native stdenv is a channel-blocking job
+Pure stdenv for native builds is a channel-blocking job
 
 Package updates might break build on the platforms of this tier and lower
 

From 0b9b6e660c553f0cedab2f04b50d3b2a85e94417 Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Sun, 12 May 2019 13:33:38 +0200
Subject: [PATCH 08/21] Fix typo

---
 rfcs/0046-platform-support-tiers.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index dc5cbe46d..fea8f7c1d 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -81,8 +81,8 @@ 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 macOS, @NixOS/aarch64-maintainers team
-should be informed.
+that was previously built succesfully on Aarch64, @NixOS/aarch64-maintainers
+team should be informed.
 
 * `x86_64-darwin`, `clang`+Darwin/macOS
 

From 8800b515ea9e4fb97044b9339778b66e36ac4874 Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Mon, 27 May 2019 00:47:45 +0200
Subject: [PATCH 09/21] Documented the three dimensions of platform support

---
 rfcs/0046-platform-support-tiers.md | 125 +++++++++++++++++-----------
 1 file changed, 77 insertions(+), 48 deletions(-)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index fea8f7c1d..5de45c503 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -48,18 +48,85 @@ such discussions more efficient.
 * Is Nix supported?
 * Are native bootstrap tools available?
 
-## Platforms
+## Main dimensions
 
-### Tier 1
+Note that Tolerance tier is never higher than Tooling tier (and normally not
+higher than Package coverage tier).
+
+### Tooling
+
+#### Tier 1
+
+A lot of packages built by Hydra, full ofBorg support, some ordinary packages
+are channel-blockers on Hydra.
+
+#### Tier 2
+
+Native bootstrap tools available, cross-build toolchains in the binary cache,
+no channel-blocking jobs on Hydra.
+
+#### Tier 3
+
+None
+
+### Tolerance/impact
+
+#### Tier 1
+
+Problems on these platforms can block updates.
+
+#### Tier 1.5
+
+Platform-specific patches expected to be applied as needed; updates expected
+not to break the build on these platforms, problems should be investigated
+(and reported to the platform maintenance team if no solution was found).
+
+#### Tier 2
+
+Platform-specific fixes are expected to be rare and non-intrusive. Updates
+might break builds.
+
+#### Tier 3
+
+Fixes necessary for this platforms must be either limited to compilation
+toolchains, or general cleanups of non-standard assumptions (e.g. «everything
+that is no 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.
+
+#### Tier 4
+
+It is recommended to keep platform-specific patches to the toolchain in a
+separate package. Cleanups not necessary on any tier-3 platforms can be
+rejected.
+
+### The number of working packages
+
+#### Tier 1
+
+Almost everything that is not explicitly platform specific and that is not
+abandoned (in Nixpkgs) works.
+
+#### Tier 1.5
 
-Aims: all packages should work (unless they don't make sense)
+Most packages work, credible ambition to reach Tier 1 at some point.
 
-A platform-specific fix is expected to be applied in `master`
+#### Tier 2
 
-Support: good binary cache coverage, full support in tooling
+Most of the popular packages work.
 
-A platform in this tier has a set of build jobs that block a channel update in
-case of failure.
+#### Tier 3
+
+Some packages work
+
+#### Tier 4
+
+Platform definitions present, a small number of packages might be working.
+
+## Current platforms
+
+### Tier 1
 
 Developer/user base: most of the Nix developers/users
 
@@ -67,13 +134,7 @@ Developer/user base: most of the Nix developers/users
 
 ### Tier 1.5
 
-Same aims and tooling support, there are channel blocking jobs
-
-Fewer developers and users, less testing — significantly more broken packages
-
-If a package update breaks a previously working package on that platform,
-update author should check if some easy fix follows from the build logs or is
-mentioned in the upstream bugtracker.
+Fewer developers and users, less testing; tier-1 tooling.
 
 * `aarch64-linux`, `gcc`+`glibc`
 
@@ -92,29 +153,14 @@ should be informed.
 
 ### Tier 2-ε
 
-Aims: most of the popular packages work
-
-Platform-specific things for arbitrary packages should not be too complicated
-
-Support: native bootstrap tools are available, cross-build toolchains in the
-binary cache, partial tooling support
-
-Pure stdenv for native builds is a channel-blocking job
-
-Package updates might break build on the platforms of this tier and lower
+Pure stdenv for native builds is a channel-blocking job; `wine` dependencies
+are available in the binary cache
 
 * `i686-linux`, `gcc`+`glibc` — `ofBorg` builds via `pkgsi686Linux`, binary
   cache contains `wine` dependencies
 
 ### Tier 2
 
-Aims: most of the popular packages work
-
-Support: native bootstrap tools are available, cross-build toolchains in the
-binary cache
-
-This tier and lower doesn't affect channel updates
-
 * `armv{6,7,8}*-linux`, `gcc`+`glibc`
 
 * `mipsel-linux`, `gcc`+`glibc`
@@ -123,11 +169,6 @@ This tier and lower doesn't affect channel updates
 
 ### Tier 3
 
-Aims: some packages are expected to work
-
-Platform-specific fixes limited to general cleanups of non-standard
-assumptions in the upstream code and basic toolchain fixes
-
 * `aarch64-none`
 
 * `avr`
@@ -160,14 +201,6 @@ assumptions in the upstream code and basic toolchain fixes
 
 ### Tier 4
 
-Aims: none
-
-Support: none or accidental
-
-Platform definitions present
-
-A small amount of packages seems to work, maybe by luck
-
 * `x86_64-linux`, `gcc`+`glibc` — static
 
 * `x86_64-linux`, `gcc`+`glibc` — `llvm` linker
@@ -182,10 +215,6 @@ Work ongoing to provide/merge Tier 4 support
 
 ### Tier 5
 
-Aims: none
-
-Support: none
-
 No current support, but previous support of clear path to add support
 
 * `aarch64-darwin`

From fb42003dd41c939374eecf2c61c6a1fc9e2ff0b2 Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Mon, 17 Jun 2019 21:42:45 +0200
Subject: [PATCH 10/21] typo fixes

---
 rfcs/0046-platform-support-tiers.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index 5de45c503..d3953fcfc 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -41,7 +41,7 @@ such discussions more efficient.
 * 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 reasonable effort?
+  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?
@@ -118,7 +118,7 @@ Most of the popular packages work.
 
 #### Tier 3
 
-Some packages work
+Some packages work.
 
 #### Tier 4
 

From 93cda2f46358a99bb871969ef0d2739774634407 Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Fri, 5 Jul 2019 01:52:11 +0200
Subject: [PATCH 11/21] Typo fix

---
 rfcs/0046-platform-support-tiers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index d3953fcfc..329ce857c 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -215,7 +215,7 @@ Work ongoing to provide/merge Tier 4 support
 
 ### Tier 5
 
-No current support, but previous support of clear path to add support
+No current support, but previous support or clear path to add support
 
 * `aarch64-darwin`
 

From ab2a70d3a32860aaf473eb53e719da7e2cb073d2 Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Thu, 18 Jul 2019 11:43:46 +0000
Subject: [PATCH 12/21] Update rfcs/0046-platform-support-tiers.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Shepherd team

Co-Authored-By: Domen Kožar <domen@enlambda.com>
---
 rfcs/0046-platform-support-tiers.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index 329ce857c..964f63c71 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -2,6 +2,8 @@
 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:
 ---

From 0d1cc2015543039a6ffc73d821457dd9210f56d1 Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Thu, 18 Jul 2019 17:27:21 +0000
Subject: [PATCH 13/21] Update rfcs/0046-platform-support-tiers.md

Typo fix

Co-Authored-By: Ryan Mulligan <ryan@ryantm.com>
---
 rfcs/0046-platform-support-tiers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index 964f63c71..8c8289737 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -2,7 +2,7 @@
 feature: platform_support_tiers
 start-date: 2019-04-28
 author: Michael Raskin
-shepherd-team: Ryan Mulligan, Jonas Pfenniger , Graham Christensen, John Ericson
+shepherd-team: Ryan Mulligan, Jonas Pfenniger, Graham Christensen, John Ericson
 shepherd-leader: John Ericson
 co-authors: Matthew Bauer
 related-issues:

From e7f66a8e3cfc0080f897deebacc94bb1b88ccd0a Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Wed, 2 Oct 2019 09:25:25 +0200
Subject: [PATCH 14/21] mention previous Solaris/Illumos support

---
 rfcs/0046-platform-support-tiers.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index 8c8289737..a8e09cc58 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -225,6 +225,10 @@ No current support, but previous support or clear path to add support
 
 * `x86_64-freebsd`
 
+* `i686-solaris`
+
+* `x86_64-illumos`
+
 ## Adding a new platform
 
 It is expected that Tier-4 support can be added freely, and Tier-3 support is

From ee057bc91d11167f6548986f869041cb5e59e70c Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Mon, 14 Oct 2019 18:05:24 +0200
Subject: [PATCH 15/21] Incorporating some feedback

---
 rfcs/0046-platform-support-tiers.md | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index a8e09cc58..f8bf82fb2 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -67,6 +67,11 @@ are channel-blockers on Hydra.
 Native bootstrap tools available, cross-build toolchains in the binary cache,
 no channel-blocking jobs on Hydra.
 
+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 Tier-1 platform (macOS),
+this requirement is not strictly mandatory for Tier-2 tooling.
+
 #### Tier 3
 
 None
@@ -165,6 +170,10 @@ are available in the binary cache
 
 * `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`
@@ -201,6 +210,8 @@ are available in the binary cache
 
 * `armv{7,8}-linux` — Android
 
+A special team @NixOS/exotic-platform-maintainers is created and can be consulted about issues related to these platforms
+
 ### Tier 4
 
 * `x86_64-linux`, `gcc`+`glibc` — static

From 0c9462fb9476caf7ae38ca58aeba8e567281c679 Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Thu, 7 Nov 2019 16:52:59 +0100
Subject: [PATCH 16/21] Edits after a (non-quorum) shepherd meeting

---
 rfcs/0046-platform-support-tiers.md | 138 ++++++++++++++++++----------
 1 file changed, 90 insertions(+), 48 deletions(-)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index f8bf82fb2..871c67ea4 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -21,7 +21,9 @@ 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.
+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
@@ -52,11 +54,19 @@ such discussions more efficient.
 
 ## Main dimensions
 
+It is expected that for a platform in a stable situation the tiers
+corresponding to all the dimensions are the same or ar most adjacent. On the
+other hand, changes to the platform tiers usually include one dimension getting
+ahead of the other, with a different balance emerging afterwards.
+
 Note that Tolerance tier is never higher than Tooling tier (and normally not
 higher than Package coverage tier).
 
 ### Tooling
 
+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).
+
 #### Tier 1
 
 A lot of packages built by Hydra, full ofBorg support, some ordinary packages
@@ -78,6 +88,10 @@ None
 
 ### Tolerance/impact
 
+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.
+
 #### Tier 1
 
 Problems on these platforms can block updates.
@@ -110,6 +124,9 @@ rejected.
 
 ### The number of working packages
 
+This dimension measures how useful is the current state of the platform support
+to the current and potential users.
+
 #### Tier 1
 
 Almost everything that is not explicitly platform specific and that is not
@@ -131,7 +148,78 @@ Some packages work.
 
 Platform definitions present, a small number of packages might be working.
 
-## Current platforms
+## Platform list
+
+The platform list will be added as an appendix to the Nixpkgs manual, and will
+be maintained as a part of the Nixpkgs documentation.
+
+A non-normative
+description of the platforms at the moment of discussion is provided in the 
+appendix to the RFC and will be used as a basis for a PR adding a platform list
+to the manual.
+
+## Adding a new platform
+
+It is expected that Tier-4 support can be added freely, and Tier-3 support is
+added once enough packages are tested and sustained development happens.
+Tier-2 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-2 tooling requirements imply allocation of some amount
+of recurring build resources (for building and testing the toolchain).
+
+Support above Tier-2 (and expectation that platform non-users pay attention to
+the platform support on updates) requires deployment of test infrastructure
+for the platform.
+
+Note that from the impact point of view Tier-3 only allows the platform to be a
+motivation for generic cleanups, and further tiers require commitment of
+recurring resources. We hope that this allows Tier-4 addition and Tier-3
+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 is
+out of scope for this RFC.
+
+# 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.
+
+# Unresolved questions
+[unresolved]: #unresolved-questions
+
+The list of currently supported platforms is 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?)
+
+# 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
 
@@ -239,49 +327,3 @@ No current support, but previous support or clear path to add support
 * `i686-solaris`
 
 * `x86_64-illumos`
-
-## Adding a new platform
-
-It is expected that Tier-4 support can be added freely, and Tier-3 support is
-added once enough packages are tested and sustained development happens.
-Tier-2 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.
-
-Support above Tier-2 (and expectation that platform non-users pay attention to
-the platform support on updates) requires deployment of test infrastructure
-for the platform.
-
-# 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.
-
-# Unresolved questions
-[unresolved]: #unresolved-questions
-
-The list of currently supported platforms is 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?)

From ebd6091491c86654cf774499889fe44fac72a509 Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Sun, 17 Nov 2019 22:21:05 +0100
Subject: [PATCH 17/21] Restructuring after a shepherd meeting

---
 rfcs/0046-platform-support-tiers.md | 265 +++++++++++++++++++---------
 1 file changed, 181 insertions(+), 84 deletions(-)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index 871c67ea4..d4db2a342 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -28,6 +28,30 @@ 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)
@@ -52,62 +76,130 @@ of the decisions of this type.
 * Is Nix supported?
 * Are native bootstrap tools available?
 
-## Main dimensions
+## 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 expectation. resource allocation 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 for a platform in a stable situation the tiers
-corresponding to all the dimensions are the same or ar most adjacent. On the
-other hand, changes to the platform tiers usually include one dimension getting
-ahead of the other, with a different balance emerging afterwards.
+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.
 
-Note that Tolerance tier is never higher than Tooling tier (and normally not
-higher than Package coverage tier).
+## Main support dimensions
 
-### Tooling
+### 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 requirments
 
 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).
 
-#### Tier 1
+### Package coverage.
 
-A lot of packages built by Hydra, full ofBorg support, some ordinary packages
-are channel-blockers on Hydra.
+This dimension measures avilability 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.
 
-#### Tier 2
+## Support tiers
 
-Native bootstrap tools available, cross-build toolchains in the binary cache,
-no channel-blocking jobs on Hydra.
+This section defines requirements and permitted impact for different support
+tiers.
 
-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 Tier-1 platform (macOS),
-this requirement is not strictly mandatory for Tier-2 tooling.
+### Tier 1
 
-#### Tier 3
+#### Impact
 
-None
+Problems on these platforms can block updates for as long as necessary to
+resolve the issue.
 
-### Tolerance/impact
+Platform-specific patches can be applied as necessary.
 
-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.
+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 1
+### 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 no x86
+is a kind of ARM» or «malloc(0) behaviour is a reliable indicator of other
+malloc features») useful for this platforms are welcome.
+
+Updates might break builds on this platform .
+
+No channel-blocking jobs on Hydra.
 
-Problems on these platforms can block updates.
+#### Tooling requirements
 
-#### Tier 1.5
+Native bootstrap tools available, cross-build toolchains in the binary cache.
 
-Platform-specific patches expected to be applied as needed; updates expected
-not to break the build on these platforms, problems should be investigated
-(and reported to the platform maintenance team if no solution was found).
+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.
 
-#### Tier 2
+#### Package coverage expectations
 
-Platform-specific fixes are expected to be rare and non-intrusive. Updates
-might break builds.
+Most of the popular packages work.
+
+### Tier 4
 
-#### Tier 3
+#### Impact
 
 Fixes necessary for this platforms must be either limited to compilation
 toolchains, or general cleanups of non-standard assumptions (e.g. «everything
@@ -116,69 +208,70 @@ 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.
 
-#### Tier 4
+#### Tooling requirements
 
-It is recommended to keep platform-specific patches to the toolchain in a
-separate package. Cleanups not necessary on any tier-3 platforms can be
-rejected.
+None.
 
-### The number of working packages
+#### Package coverage requirements
 
-This dimension measures how useful is the current state of the platform support
-to the current and potential users.
+Some packages work.
 
-#### Tier 1
+### Tier 5
 
-Almost everything that is not explicitly platform specific and that is not
-abandoned (in Nixpkgs) works.
+#### Impact
 
-#### Tier 1.5
+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.
 
-Most packages work, credible ambition to reach Tier 1 at some point.
+#### Tooling requirements
 
-#### Tier 2
+None.
 
-Most of the popular packages work.
+#### Package coverage requirements
 
-#### Tier 3
+Platform definitions present, a small number of packages might be working.
 
-Some packages work.
+### Tier 6
 
-#### Tier 4
+Work ongoing to provide/merge Tier 5 support
 
-Platform definitions present, a small number of packages might be working.
+#### Impact
 
-## Platform list
+Platform definitions and separate platform-specific toolchain packages can be
+included.
 
-The platform list will be added as an appendix to the Nixpkgs manual, and will
-be maintained as a part of the Nixpkgs documentation.
+### Tier 7
 
-A non-normative
-description of the platforms at the moment of discussion is provided in the 
-appendix to the RFC and will be used as a basis for a PR adding a platform list
-to the manual.
+No current support, but previous support or clear path to add support
 
-## Adding a new platform
+## Platform lifecycle
 
-It is expected that Tier-4 support can be added freely, and Tier-3 support is
+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-2 support (and higher tolerance to platform-specific fixes in
+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-2 tooling requirements imply allocation of some amount
+platform. Note that Tier-3 tooling requirements imply allocation of some amount
 of recurring build resources (for building and testing the toolchain).
 
-Support above Tier-2 (and expectation that platform non-users pay attention to
-the platform support on updates) requires deployment of test infrastructure
-for the platform.
+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-3 only allows the platform to be a
+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. We hope that this allows Tier-4 addition and Tier-3
+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 is
-out of scope for this RFC.
+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-specifing patches no longer
+permissible in the context of the new support tier can be removed at will by
+the package maintainers.
 
 # Drawbacks
 [drawbacks]: #drawbacks
@@ -195,10 +288,12 @@ 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 is incomplete.
+The list of currently supported platforms might still be incomplete.
 
 # Future work
 [future]: #future-work
@@ -216,6 +311,9 @@ 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.
+
 # Appendix A. Non-normative description of platforms in November 2019
 
 We currently have a relatively steady state, so the tiers for each platform do
@@ -227,9 +325,9 @@ Developer/user base: most of the Nix developers/users
 
 * `x86_64-linux`, `gcc`+`glibc`
 
-### Tier 1.5
+### Tier 2
 
-Fewer developers and users, less testing; tier-1 tooling.
+Fewer developers and users, less testing; Tier-1 tooling.
 
 * `aarch64-linux`, `gcc`+`glibc`
 
@@ -246,15 +344,14 @@ 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 2-ε
-
-Pure stdenv for native builds is a channel-blocking job; `wine` dependencies
-are available in the binary cache
+### Tier 3
 
 * `i686-linux`, `gcc`+`glibc` — `ofBorg` builds via `pkgsi686Linux`, binary
   cache contains `wine` dependencies
 
-### Tier 2
+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`
 
@@ -266,7 +363,9 @@ are available in the binary cache
 
 * `x86_64-linux`, `gcc`+`musl`
 
-### Tier 3
+### Tier 4
+
+A special team @NixOS/exotic-platform-maintainers is created and can be consulted about issues related to these platforms
 
 * `aarch64-none`
 
@@ -298,15 +397,13 @@ are available in the binary cache
 
 * `armv{7,8}-linux` — Android
 
-A special team @NixOS/exotic-platform-maintainers is created and can be consulted about issues related to these platforms
-
-### Tier 4
+### Tier 5
 
 * `x86_64-linux`, `gcc`+`glibc` — static
 
 * `x86_64-linux`, `gcc`+`glibc` — `llvm` linker
 
-### Tier 4.5
+### Tier 6
 
 Work ongoing to provide/merge Tier 4 support
 
@@ -314,7 +411,7 @@ Work ongoing to provide/merge Tier 4 support
 
 * `powerpc64le-linux`, `gcc`+`glibc`
 
-### Tier 5
+### Tier 7
 
 No current support, but previous support or clear path to add support
 

From a2883074b2b12987d07bd47d41036b1a2cf1081c Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Mon, 18 Nov 2019 08:13:58 +0000
Subject: [PATCH 18/21] Apply typo fixes from code review

Co-Authored-By: Ryan Mulligan <ryan@ryantm.com>
---
 rfcs/0046-platform-support-tiers.md | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index d4db2a342..f7ee76cf9 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -95,7 +95,7 @@ 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 expectation. resource allocation and project priorities. As this is not
+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.
 
@@ -113,14 +113,14 @@ 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 requirments
+### 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.
+### Package coverage
 
-This dimension measures avilability of the most important packages on the
+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.
 
@@ -176,11 +176,11 @@ Most packages work, credible ambition to reach Tier 1 coverage at some point.
 
 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 no x86
+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 this platforms are welcome.
+malloc features») useful for these platforms are welcome.
 
-Updates might break builds on this platform .
+Updates might break builds on this platform.
 
 No channel-blocking jobs on Hydra.
 
@@ -203,7 +203,7 @@ Most of the popular packages work.
 
 Fixes necessary for this platforms must be either limited to compilation
 toolchains, or general cleanups of non-standard assumptions (e.g. «everything
-that is no x86 is a kind of ARM» or «malloc(0) behaviour is a reliable
+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.
@@ -269,7 +269,7 @@ 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-specifing patches no longer
+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.
 

From f053b7a58f693425acbe3887e70fc3efde7f9ea5 Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Mon, 18 Nov 2019 09:28:49 +0100
Subject: [PATCH 19/21] A bit more future work

---
 rfcs/0046-platform-support-tiers.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index f7ee76cf9..3990722ae 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -314,6 +314,10 @@ 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

From a259e1a1cde4dcaa3d76f5dbedde0c96a52be0c9 Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Wed, 25 Dec 2019 13:32:22 +0100
Subject: [PATCH 20/21] Accept the point about primary importance of ABI

---
 rfcs/0046-platform-support-tiers.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index 3990722ae..25eb5a024 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -55,9 +55,10 @@ met.
 ## Platform elements
 
 * CPU architecture (possibly: subarchitecture, optional features)
-* OS kernel
+* OS ABI
 * C compiler
 * C library
+* OS kernel
 * NixOS/non-NixOS global layout, in case of Linux with glibc
 * Global linking options
 

From 8ec08fc0bd8292de934a0c60496df66010a98d58 Mon Sep 17 00:00:00 2001
From: Michael Raskin <7c6f434c@mail.ru>
Date: Thu, 2 Jan 2020 15:07:06 +0000
Subject: [PATCH 21/21] =?UTF-8?q?Modernise=20the=20grammar=20choice?=
 =?UTF-8?q?=E2=80=A6?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Michael Peyton Jones <me@michaelpj.com>
---
 rfcs/0046-platform-support-tiers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rfcs/0046-platform-support-tiers.md b/rfcs/0046-platform-support-tiers.md
index 25eb5a024..59a02ea0c 100644
--- a/rfcs/0046-platform-support-tiers.md
+++ b/rfcs/0046-platform-support-tiers.md
@@ -64,7 +64,7 @@ met.
 
 ## Questions to answer for each platform
 
-* What fraction of packages is expected to work?
+* 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?