Oh, one thing to point out is that the technical differences between current arm-linux-androideabi at tier 2 and at tier 1 are quite minor, and are mostly about what we are guaranteeing, and the message we are sending to users. This target already has 1st-tier test coverage, so promoting it to tier 1 could be as little as updating the platform support page.
One technical change that could be desirable in a tier 1 platform is testing on actual hardware, not on emulators. And that’s a big change that we have no way to support today within our CI.
I’ve for a while been slightly dissatisfied with the picture painted by the platform support page. It divides tiers at a course level and doesn’t make clear that some tier 2 targets have excellent CI and some have poor CI. Other factors that should influence people’s perceptions of Rust platform support should be “is this target automatically tested”, and “does rustup support this target”, and “does rustup run on this target”. Furthermore, it’s not obvious to me that the division between the “rustc” and “cargo” columns provides any value at this stage. To me, Rust has either target support, target + host support, target + rustup support, target + host + rustup support; and then there’s the coverage dimension. A target that has rustc support but not cargo support is basically tier 3 unusable, may not be worth mentioning the distinction, or tier 2 hosts could by definition support cargo.
I also am inclined to split tier 2 into 2 tiers, creating a 4 tier system. Some of the tier 2 stuff should not be “guaranteed” in any way, as stated in the tier 2 definition.