Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Promote Redox to Tier 2 Platform #43206

Closed
jackpot51 opened this Issue Jul 13, 2017 · 10 comments

Comments

Projects
None yet
6 participants
@jackpot51
Copy link
Contributor

jackpot51 commented Jul 13, 2017

Redox is unique among targets. It has libstd support down to the syscall level, completely in Rust. For a while, it has been a Tier 3 platform (https://forge.rust-lang.org/platform-support.html). Due to recent advances in Redox, I think it is now time to promote it to a Tier 2 platform.

What this would entail is the merging of this changeset: master...redox-os:master

To summarize, this adds a docker CI image for Redox, adds the CI image to Travis, and fixes any remaining compilation problems with Redox.

The benefits of this are as follows:

  • Easier to develop for Redox - rustup target add x86_64-unknown-redox
  • Ensuring that changes to libstd also get propogated to sys::redox
  • Improving Redox support further
  • Eventually packaging rustc and cargo for Redox

@jackpot51 jackpot51 changed the title Build Redox libstd using travis Promote Redox to Tier 2 Platform Jul 13, 2017

@jackpot51

This comment has been minimized.

Copy link
Contributor Author

jackpot51 commented Jul 13, 2017

@brson @alexcrichton @sfackler @BurntSushi @japaric @steveklabnik I am curious about your opinions

(And anyone else who wants to discuss)

@aturon

This comment has been minimized.

Copy link
Member

aturon commented Jul 13, 2017

cc @rust-lang/core for policy issue here.

Note that in general, we have several other outstanding requests for additional platform support, which are currently awaiting a general policy decision.

@sfackler

This comment has been minimized.

Copy link
Member

sfackler commented Jul 13, 2017

If we did this, what level of effort would we need to put forward when implementing new APIs other than making sure the Redox build still compiles? For example, would it still be acceptable to stub out the implementation of TcpStream::connect_timeout with one that just returns an error?

@jackpot51

This comment has been minimized.

Copy link
Contributor Author

jackpot51 commented Jul 13, 2017

Absolutely @sfackler. Returning ENOSYS for new API would be acceptable, but we would fill in the stubs as soon as possible.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Jul 17, 2017

@jackpot51

Due to recent advances in Redox, I think it is now time to promote it to a Tier 2 platform.

Forgive my ignorance, but I'm curious what advances you are referring to? (Just a link or two would suffice.)

@jackpot51

This comment has been minimized.

Copy link
Contributor Author

jackpot51 commented Jul 17, 2017

The news articles since This Week in Redox 20, found here https://www.redox-os.org/news/ , sum it up

@aturon

This comment has been minimized.

Copy link
Member

aturon commented Jul 17, 2017

@jackpot51 I had a chance to talk with core team and infra folks about this question. In principle, we're open to moving platforms to tier 2 as long as there is solid evidence that community members will quickly address issues or blockages that arise -- and it's clear that Redox meets that bar.

However, at the moment, we are also at the limit of our build capacity. We're in the process of adding more capacity, but it will take some time. We should pick back up the discussion at that point.

To set clear expectations: in the long run, we want to move to a broader sponsorship funding model, so that we can support a wider array of platforms based on community support and demand. We're still working out the details and policies around that, though. In the short term, however, I expect we'll have enough extra capacity that we could do this for some time.

@jackpot51

This comment has been minimized.

Copy link
Contributor Author

jackpot51 commented Jul 17, 2017

@aturon @sfackler @nikomatsakis @brson Here is an implementation: #43303

bors added a commit that referenced this issue Aug 15, 2017

Auto merge of #43303 - redox-os:redox_docker, r=alexcrichton
Add Redox Dockerfile and Travis Environment

This adds Redox to the Travis build. This is an example implementation of #43206

bors added a commit that referenced this issue Aug 15, 2017

Auto merge of #43303 - redox-os:redox_docker, r=alexcrichton
Add Redox Dockerfile and Travis Environment

This adds Redox to the Travis build. This is an example implementation of #43206
@musoke

This comment has been minimized.

Copy link
Contributor

musoke commented Aug 22, 2017

Is this issue closed by #43303 ?

@jackpot51

This comment has been minimized.

Copy link
Contributor Author

jackpot51 commented Aug 22, 2017

Yes, it is.

@jackpot51 jackpot51 closed this Aug 22, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.