That doesn’t imply end users of niche architectures are supposed to lose their favorite apps.
Just support macOS, RHEL/SLES, Debian, Ubuntu and Windows.
Everything else gets tagged with “UNSUPPORTED/WONTFIX”.
But please don’t complain when your favorite operating system is not supported.
Or, you know, we could just stop trying to tell others what targets to use.
And, FWIW, Rust is actually getting support for more architectures thanks to the GCC codegen and GCC frontend.
:-).
Vive la difference.
Case in point - the gcc projects for rust are not officially supported by rust. They are alternative rust compilers - the authors of those have explicitly stated they will follow the features (etc) of the official rustc, and maybe the rust language team will consider those other compilers when designing new features, but it's not on the rust language team to do so.
Another case in point - many projects don't support most linux distros. The job of the linux distro is maintain a fork (usually in the form of patches against upstream in the source package) of the software that works well with their system.
If it's not ok to tell others what targets to use, then it's also not ok to tell others what targets to support.
Who decides what degree of “popularity” is sufficient to maintain default support?
I don't think anyone is complaining about well written fully functioning patches, that break no existing features or OSes.
While most wouldn’t be complaining, I think any maintainer should absolutely feel free to refuse a well-written, fully working patch for any reason. For example, that patch may be too large or too complex, thus might become a liability at some point in the future. Maybe managing user expectations is a priority for the maintainer. Maybe they wish to reduce support burden because they’d like spend more time with their family. All that should be deemed normal and acceptable.
It can feel disappointing (numerous pull requests that I wrote have been denied or ignored), but I think it’s important that we, as a community, normalize that.
"This bug report has been reviewed and can't continue without more information. This report is now considered inactive unless you do these prescribed actions and report back with this specific information. Click here to submit this specific information."
Each upstream project and upstream distro is responsible for deciding on such a policy for themselves.
Many upstream distros do just that already with their packaging. For example, you may not find a Linux kernel image that will work on your Pentium III CPU on Debian’s main repositories. Or an OpenSSL binary package.
Such decisions are highly arbitrary and at the discretion of the people who do the maintenance work and pay the hosting bills.
Being able to draw the line somewhere is a feature. It can help keep maintainers from burning out or giving up under the load of support requests.
Given the situation of a specific project, its individual goals, and the people involved, I would expect their decision to take into account many more factors than just the “so disused that no one complains” axis.
In this case it does, for everyone out there on a RISC-V system who wants to use one of the over 400,000 programs which depend on cryptography.
Secondly, let’s assume – in favor of your argument – that for some reason, it’s still not working for RISC-V users. Then what keeps them from volunteering their time, labor, or money, and help make the thing fly and keep it that way? Niche or single-purpose distributions (such as Arch Linux ARM or AmberElec) have been doing just that anyway: those people regularly maintain special patches in order to support their specific target anyway, no matter whether the upstream projects are even interested in their platform, or whether they’re accepting their patches.