Form a libs team?

[japaric]

We've received quite a few crate requests in the 2019 wishlist survey. Those requests are listed below from most voted to least voted:

• An easy to use USB device library
• An easy to use USB host library
• An easy to use pure-Rust RTOS
• An easy to use SD/MMC and FAT32 library
• High quality RTOS bindings
• A task scheduler
• GUI with desktop simulation support

The first two requests might fit within the scope of the HAL team but the rest don't fit within the scope of any of the other teams we currently have.

The question is: should we create a new libs team dedicated to cater to these requests?

My opinion is that we should create a libs team but should not add non-architecture specific (i.e. general purpose) crates to the org. Instead the libs team should follow the lib blitz model to help grow crates developed by the community.

The reasons why I think we should, in general (*), not maintain or develop general purpose no-std crates in the org are:

• Increased maintenance load (the WG currently owns 38 repos)

• Some crates require specialized knowledge (e.g. USB), which means we'll have to further increase the WG membership (the WG currently has 26 members)

• Trade-offs in library design often lead to competing implementations (e.g. RTOS-es), which is a good thing because people have different needs (e.g. some may prefer ease of use over flexibility) -- more options means they can pick what suits them best. Taking a crate into the org effectively blesses it (i.e. it puts a "WG approved" stamp on it). This, I think, would be rather harmful in the early stages of the embedded ecosystem as it would prevent other implementations from competing on equal footing.

(*) of course, every rule has it exception. I think for example that, once mature, a core usb crate along the lines of the http crate would be reasonable to have under the org and the maintenance of the HAL team.

Apart from preventing the above issues, following the lib blitz model means that we'll get to observe API design patterns emerge in the development of several libraries, which we can then add to our docs for the benefit of the whole embedded community.

Thoughts on the general direction? (There are plenty of details to hash out; the lib blitz model aims to take crates to 1.0 status whereas we would likely have to work with crates in their early development stages)

[korken89]

I agree on having a libs team following the lib blitz way. I think that having no general libraries, to burden the WG with too much work, is good.
Just to be careful to not include too much too fast.

[thejpster]

I agree with everything @japaric said.

[japaric]

Just to be careful to not include too much too fast.

Yeah, so I was thinking we could have some cool down period between crate reviews. Perhaps something like 2 weeks for reviewing the crate and working with author and then 1 or 2 weeks of no review where we just decide which crate to work on next.

To account for the crate requests in #256 we could prioritize working on crates that have been explicitly requested and the libs team has picked as a focus for this year.

[Dirbaio]

The libs team exists now! #707