[RFC] Embedded Rust Showcase #187
Conversation
|
Thanks for writing this, @adamgreig! This proposal (PR) needs at least 10 votes (approvals) from @rust-embedded/all @rust-embedded/all please vote on this proposal using [pull request reviews]. |
japaric
added
the
needs-decision
There was a problem hiding this comment.
This is very good, thank you @adamgreig!
I have some notes, although I won't veto this proposal over any of them.
rfcs/0000-embedded-rust-showcase.md
Outdated
|
|
||
| ## New Repository | ||
|
|
||
| We create a new repository, `embedded-rust-showcase` (TBC), in the |
There was a problem hiding this comment.
Can be shortened to just showcase, due to the org namespace: rust-embedded/showcase
rfcs/0000-embedded-rust-showcase.md
Outdated
|
|
||
| ## New Web Page | ||
|
|
||
| The new web page would live at https://showcase.embedded-rust.org (TBC). |
There was a problem hiding this comment.
You mean http://www.rust-embedded.org/? embedded-rust.org is crurrently unregistered.
rfcs/0000-embedded-rust-showcase.md
Outdated
| * Whether or not the project builds on stable Rust | ||
|
|
||
| After a project is submitted, the resources team will review the PR and | ||
| vote on inclusion. They may consult other relevant teams in the process, |
There was a problem hiding this comment.
Maybe a full vote is overkill. This isn't some highly sensitive decision. If one or two team members think something should be included, I think that's good enough.
| * The web page could instead be maintained as part of the main embedded-rust | ||
| website, existing as a page in that website. | ||
| * We could extend awesome-embedded-rust to permit longer descriptions of | ||
| projects. |
There was a problem hiding this comment.
I think it would be better to keep the showcase separate and focus awesome-embedded-rust on libraries, tools, etc.
rfcs/0000-embedded-rust-showcase.md
Outdated
|
|
||
| * Final name for repository/web page | ||
| * The specific technical solution for rendering the repository contents to a | ||
| web page |
There was a problem hiding this comment.
I don't think that last point needs to be part of the RFCs. As long as we agree on the general idea (i.e. static website generator), whoever ends up implementing it is most qualified to decide whether to use Jekyll, Gutenberg, or whatever else.
|
Thanks for the comments @hannobraun! I think they're worth including and I'll update the RFC with them this evening. |
|
I had some time so addressed your comments in 4177a15 (though this has dismissed your review). |
rfcs/0000-embedded-rust-showcase.md
Outdated
|
|
||
| The objective of this list is to showcase Rust code in action; we can't do this | ||
| if people can't read the code! There might be space on the main Embedded Rust | ||
| website to showcase projects known to use Rust but without public code. We |
There was a problem hiding this comment.
To me if the code is available to the public it is very much the meaning of the term open source. I think what you're trying to say is that the specific choice of license doesn't matter as long as the source is available. Not sure how to properly word that, though.
There was a problem hiding this comment.
I don't understand what change you'd like: the RFC already says the code must be publicly available but that it doesn't require an open source license.
There was a problem hiding this comment.
Not sure, just reads odd to me. It kind of implies open source in the definition of the OSI which many people do not agree with. Maybe shorten the sentence to: "We don't require any specific license; just that
it's publicly available for interested users to read."?
rfcs/0000-embedded-rust-showcase.md
Outdated
| which is useful to establish if a project works on stable Rust. | ||
|
|
||
| * Have at least one photograph/video/GIF of the project in action | ||
|
|
There was a problem hiding this comment.
I would like to make build/configuration/installation instructions at least a soft requirement so that interested parties can reproduce the work or at least have a rough guideline for their own projects.
There was a problem hiding this comment.
How should we specify a soft requirement? I was thinking that if CI is working that means it should be pretty easy to figure out how to build the project, but since this showcase is about complete projects I don't imagine many people will be reproducing the whole project anyway (you'd presumably need custom hardware); instead we want to show off what projects are possible.
There was a problem hiding this comment.
I will be one of those curious people that will compile the project just to see how big the binary is. I might also look at some parts of the disassembly, in particular interrupt handlers, if it seems that the program contains time sensitive / real time portions. So I would give extra points for build instructions and double extra points if the CI includes the output of size.
There was a problem hiding this comment.
That's fair. Do you think having working CI is enough of a requirement or do we want to require specific build instructions too?
There was a problem hiding this comment.
I will first try cargo build --release (on w/e rustc channel I happen to be on) and then check the CI builds if that doesn't work but I'm sure most people will give up after the first error so I would say include build instructions if it's more complex than doing cargo build --release from the root of the repo -- assuming that the user will have stable as their default channel. If nightly is required they can just put a rustc-version file in the root of the repository and not write build instructions.
There was a problem hiding this comment.
Well, the project may or may not require custom hardware but with embedded projects there're more steps involved than just "fire up the compiler, then run it". It may require custom hardware or run on a development board. It's likely to require additional hardware, then it would be interesting how that is hooked up. Even if an interested reader is not capable or willing to reproduce it it might spark ideas for new projects or animate to tinker which I think would be a nice outcome of the showcase display.
|
@adamgreig Thanks for writing this up, this looks very good to me. |
|
I've updated to address @therealprof 's comments. |
There was a problem hiding this comment.
Great idea. I think this is great for pulling in more people who may have a primary interest in building things and a secondary interesting in building them in Rust.
I think this could also appeal to those that are already Rust developers and looking to see what you can actually do on the embedded front (project ideas that are concrete).
|
This RFC is now officially approved so I'm going to merge it. bors r+ @rust-embedded/resources anyone up for implementing this? We used Gutenberg for the blog, perhaps there's some template we could use here? |
187: [RFC] Embedded Rust Showcase r=japaric a=adamgreig Follow-up from #147 and today's IRC meeting. [Rendered](https://github.com/rust-embedded/wg/blob/embedded-rust-showcase/rfcs/0000-embedded-rust-showcase.md) cc @rust-embedded/resources Co-authored-by: Adam Greig <[email protected]> Co-authored-by: Adam Greig <[email protected]>
Build succeeded |
Follow-up from #147 and today's IRC meeting.
Rendered
cc @rust-embedded/resources