I am willing to dedicate some amount of my own time to make it happen but am not convinced that my skills [2] and the amount of time I have available to spend is sufficient to make a difference.
The next tier 1 is going to be ARM, probably for both Android and Linux, and then I personally don't see any others on the horizon. I actually see our tiers being redefined soon to be more graduated, and not have so many tier 2 commitments (we're happy to build artifacts for obscure platforms, less happy to be on the hook for guaranteeing obscure platforms continue to build - not saying FreeBSD specifically is 'obscure').
That said, the differences between tier 1 and tier 2 are not so great. If a platform has testing on CI then it is pretty close to tier 1, even if it's technically tier 2. The problem here is that testing the FreeBSD targets requires running FreeBSD in some way and that has been hard for our CI to do. Anything that can be crossed from Linux is easy, everything else is a painful special case. So with FreeBSD we do the the cross-building, but not the cross-testing. So the most effective thing to do to take Rust FreeBSD support to the next level is to figure out a way to get the CI to run tests.
There may be opportunities in the future for paid Rust platform support, where if a motivated party donates the right amount of money, we'll make it happen. I think that will have to happen to get some of the remaining platforms up to production quality.
If I were to set up my own FreeBSD buildbot for commits to the Rust repos, would result reports from my buildbot be welcome? Would automatic reports be useful to you, or should I manually inspect failures and write up a bug report / pull request with fixes for issues that arise? If automatic, how could I best integrate reports of failure with your development process for Rust?
>There may be opportunities in the future for paid Rust platform support, where if a motivated party donates the right amount of money, we'll make it happen. I think that will have to happen to get some of the remaining platforms up to production quality.
I like this idea though I don't have a lot of money to spend myself currently.
We have a "meta CI" system called bors/homu that integrates with other CI, currently Travis and AppVeyor. bors works with any service that can post a result to a GitHub PR.
So the plan for supporting further architectures is to create a small custom runner that builds, tests and posts to the PR. That code does not exist yet, but if it appeared there are likely several upcoming architectures that could make use of it.
With that tool, we could allow contributors to set up their own integration bots and hook into our CI.
If anyone is interested, it'd probably be quite easy to adapt for running rust tests inside a FreeBSD vm:
https://evilpiepirate.org/git/ktest.git
If anyone is interested I'd be happy to walk someone through what it does and what parts you'd want.
In general, the differences between Tier 2 and Tier 1 are:
1. Get tests running on every commit.
2. Gate building on those tests passing.
The first is a technical/money issue, the latter is a social issue. That is, getting all tests working is technical, being able to afford running them on every commit is monetary, but gating builds on failures on a platform is an issue of "who is responsible for making sure things stay passing."
Given that we run these tests on every commit, in some sense, it would be the PR author's job, but if they get stuck, we need someone who's able to help them fix that. That is the hardest part of moving from tier 2 to tier 1 in my personal opinion. Who is that person? What happens if they drop off the project?
I would have liked to volunteer as the kind of person that would investigate issues for the FreeBSD platform but as I said, both my skills and my time are limited to the extent that they might not be sufficient.
As for what happens if the person responsible for this drops off the project, I think the solution to that is not so complicated; demote the platform back to tier 2 until someone else (if anyone ever) steps up to take over the responsibility.
I expect that your situation isn't uncommon, maybe the solution is two or three people rather than one. Raises that bar though...
Sounds like a good idea to me. Personally I would be willing to work with a couple of other volunteers as long as we were able to get along.