In the past few weeks, there have been some improvements on testing cross-compiled targets, mainly Android and ARMv7. It is now possible to run the tests in emulators (Android/QEMU), or on a real remote device (ARM).
With these, I think technically we might have what we need to make these platform Tier 1. Are there any unresolved problems left? Technical issues? Can we provide the necessary support for these targets? Can we make them Tier 1?
Over time our definition of tiers has started to show its age I think, unfortunately. While the strict definition of “Tier 1” is that we’re running tests and building nightlies, ARM still doesn’t “feel” tier 1 worthy to me at least. For example the x86_64/i686 targets all feel very tier-1-esque because we can say things like:
We can say a lot of these things for ARM targets as well, but the crucial one I feel is missing is the definition of what “ARM” even is. What architectures/platforms does each platform correspond to? What instruction sets are we allowed to use? These basic definitions are loosely there today but we’d need to crystallize exactly what’s going on here before, at least in my mind, promotion to tier 1.
I think furthermore we need a or a team of champions for the ARM target. In general this is a group of people that can get tagged in on ARM-related questions and can be thought of as experts for the ARM target. The group here for x86_64/i686 is quite large (a lot of contributors can help out!) but for ARM it’s less clear. The tl;dr; here is that if we get a bug report about instructions or instruction sets, we should be able to answer it instead of having to just shrug saying “well that’s LLVM for you”
Beyond what @alexcrichton said, there are a number of factors that make us wary of making significant changes to our support commitments right now. Maintaining what we are already committed to is brutal, in terms of manpower, and financial expense. There seems to be a general feeling among the infrastructure team that we need to regroup on the entire structure before making any big moves.
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.
A lot of the Tier 2 Linux arches get delayed testing from the distros. In Fedora, we have native builds for armv7hl, aarch64, ppc64, ppc64le, and s390x (and of course Tier 1 i686 and x86_64). But these builds are still manual, so I usually only discover issues when I try scratch builds of beta rust. I would love to find a way to contribute more automated testing of all these on the master branch!
@cuviper we should definitely talk sometime. I think the infra team will be regrouping on this issue soon.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.