Pre-RFC: embedded-rust-community organization

[jamesmunns]

In the last embedded-wg meeting, we discussed having an "embedded-rust-community" organization, with a lower threshold to inclusion of members, maintainers, and crates.

The idea would be to allow a bit more centralization and focus of ideas that are good, but have not reached the critical mass/core functionality that would drive them being maintained by the limited embedded-wg resources.

See the relevant discussion from the IRC meeting.

In particular, this effort draws from the following prior-art:

• rust-lang-nursery
• rust-bus

This may be a good focus for the proposed/accepted Ecosystem Team.

CC @mathk and @MabezDev, as you have expressed interest in joining the ecosystem team.

[thejpster]

I think AUR also works as a model: https://aur.archlinux.org/. I believe Ubuntu and Fedora do something similar.

[ryankurte]

I still really like the idea of this, especially as a collective / home for done packages to share maintenance and support

[adamgreig]

I like the idea but I think it could work just fine as part of rust-embedded itself, without needing a whole separate organisation. We could just have a team to manage those repositories. I think @jonas-schievink mentioned that rust-lang itself has a bunch of repositories in a step away from separate organisations. It could also help with #266 and #431.

[jonas-schievink]

Having it as part of rust-embedded would probably help with the discoverability a lot, too.

[ryankurte]

imo it's useful to maintain some separation between core rust-embedded things and the wider ecosystem, particularly as one would expect orders of magnitude more repositories (and thus noise) from the collective.

i imagined something more like, you add your project to the collective and maintain authorship but reduce bus factor / share maintaining effort with others as required, as opposed to, finish driver and pass off to rust-embedded/ecosystem (and then join the ecosystem team? idk)

[MabezDev]

Apologies, I completely forgot about this! I meant to get back to this after I finished up my final year, whoops! I'm still very interested in helping out with something like this!

Am I right in assuming this would be a case of extending support to core embedded projects that are currently outside of the rust-embedded org? For example a project like smoltcp; I know there have been talks aready about it, but I think its sat in its own org at the moment.

As a counter example, I feel like driver crates and HAL's aren't the sort of thing to include; as embedded Rust grows the number of these crates would be massive, and for many (particularly driver) crates don't require much maintainance at all, if any.

[adamgreig]

Possibly we need to address two types of project here:

• one is larger and widely useful embedded projects (like smoltcp, or like other recent crates such as r0, bare-metal, or mutex-trait that don't really have a good place in the org at the moment) which might move to rust-embedded to help ensure continuity and maintenance; we'd expect these to be either larger projects or very widely applicable projects, but there might still be distinctions between 'official' wg projects where we promise support and 'unofficial' projects where we are hosting a project but don't make the same guarantees. I really think these should be in rust-embedded but need a new team to manage maintaining them, especially crates we're more 'adopting' rather than making a core rust-embedded project.

• another is the larger number of small projects like a driver for some I²C sensor where the author wants it to have a home beyond their private github and/or wants to share maintenance and/or doesn't have time for maintenance but the community might be able to do the occasional bit of fixing/releasing, where we have a very low threshold of entry and lots of people can be in the maintenance team, and many projects might be nominally 'complete' and only need occasional un-bit-rotting due to Rust updates or ecosystem library updates. These crates might be a better fit for a separate org or perhaps just shouldn't be included at all.

Personally I think we could have both types of projects in rust-embedded; we'd have one or two new teams to manage maintenance, and it'd be nice for the new team members to be part of the 'official' rust-embedded org and that same brand name helps the maintained projects get exposure and support. I worry that a separate '-community' org would basically be its own island without the support or momentum of the main wg org (as has basically happened with rust-embedded-community).

@MabezDev

As a counter example, I feel like driver crates and HAL's aren't the sort of thing to include

I can see this both ways... on the one hand, most of these seem better suited to their own orgs (nrf-rs, stm32-rs, etc), and that seems to work for platform-specific stuff. Driver crates for random ICs are less clear, so far I think they're basically all just on people's private githubs, which also seems to be working OK. But, it might be really nice to have a bunch of driver crates eventually mature into being hosted by rust-embedded, and in the future when someone's looking on crates.io (or our own list of drivers!) there's a whole bunch of crates you can count on to still be around and supported in the future, not tied to a single person.

[eldruin]

The rust-embedded-community has been created. Its meta repository offers a place for further discussion.
Closing this.

[hannobraun]

@eldruin: Your "meta repository" link links to the org. Correct link: https://github.com/rust-embedded-community/meta