5 ms·

I am glad that FreeBSD is on the "Tier 2" list of supported platforms [1] but am wondering, is there any way to convince you guys to make it "Tier 1"? If so, ho

I am glad that FreeBSD is on the "Tier 2" list of supported platforms [1] but am wondering, is there any way to convince you guys to make it "Tier 1"? If so, how? 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. [1]: https://forge.rust-lang.org/platform-support.html https://forge.rust-lang.org/platform-support.html [2]: https://www.github.com/eriknstr https://www.github.com/eriknstr

steveklabnik 10y ago
Semi-official answer since this isn't an area I work on directly: 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?
- eriknstr 10y ago
  >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.
  - steveklabnik 10y ago
    Yeah, I think that policy is sound, it's just something we haven't actually done yet, so there are inevitable kinks to work out :) I expect that your situation isn't uncommon, maybe the solution is two or three people rather than one. Raises that bar though...
    - eriknstr 10y ago
      >maybe the solution is two or three people rather than one 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.
    - Manishearth 10y ago
      One of the kinks is the longevity guarantee -- we kinda-sorta guarantee that Tier 1 platforms will "never" go away, but we can't as easily do that for a community thing. AIUI Tier 1 is something permanent that you can rely on always existing in the future.
brson 10y ago
I think it is unlikely we will make FreeBSD tier 1 any time soon. The project is stretched beyond its limits with its platform support commitments, and FreeBSD is historically difficult for us to support. 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.
- eriknstr 10y ago
  >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. 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.
  - brson 10y ago
    We no longer use buildbot for our CI. 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.

steveklabnik 10y ago

Semi-official answer since this isn't an area I work on directly: 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?

eriknstr 10y ago
>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.
- steveklabnik 10y ago
  Yeah, I think that policy is sound, it's just something we haven't actually done yet, so there are inevitable kinks to work out :) I expect that your situation isn't uncommon, maybe the solution is two or three people rather than one. Raises that bar though...
  - eriknstr 10y ago
    >maybe the solution is two or three people rather than one 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.
  - Manishearth 10y ago
    One of the kinks is the longevity guarantee -- we kinda-sorta guarantee that Tier 1 platforms will "never" go away, but we can't as easily do that for a community thing. AIUI Tier 1 is something permanent that you can rely on always existing in the future.

brson 10y ago

I think it is unlikely we will make FreeBSD tier 1 any time soon. The project is stretched beyond its limits with its platform support commitments, and FreeBSD is historically difficult for us to support. 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.

eriknstr 10y ago
>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. 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.
- brson 10y ago
  We no longer use buildbot for our CI. 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.