Meeting 2024-07-30

[adamgreig]

This is the agenda for today's meeting. Please add anything you'd like to discuss below!

• Meetings: Tuesday 8pm Europe/Berlin time
• Join the Matrix chat
• Nominated issues
• IRC/Matrix logs

Announcements

• Welcome @jannic to the triage team!

[jamesmunns]

I realized that the Rust survey team has the option to run "micro surveys" on behalf of Rust teams: https://github.com/rust-lang/surveys/blob/main/micro-surveys.md

I wonder if it's worth us putting together a survey for the embedded ecosystem, asking things like:

• Are you currently using embedded rust for hobby/school/work/none/in the past but not now?
• How long have you been using embedded Rust (0-6+ years)
• If using for work, how many devices/year is your company shipping currently using Rust?
• What architectures are you using (Arm/RISC-V/Xtensa/other)
• What chip families are you using (STM32/nRF52/RP/ESP32/etc)
• What frameworks/RTOSs are you using (Bare/Embassy/RTIC/Tock-OS/ESP-IDF/Hubris/other)
• How are you using Rust? (Only Rust, Rust as primary with C components, C as primary with Rust components, Rust tooling only (off device))
• What tools do you use as part of your development process (Cargo, probe-rs, defmt, other)
• What are the most common crates/libraries you use in your projects (free entry)
• What are your biggest complaints or blockers for using Rust in your projects (free entry)?
• How happy are you with using Rust for embedded (1-10)?

Open to feedback and suggestions for questions, note that we should not ask for any PII or DEI information, as per the micro survey guidelines

[jamesmunns]

Pinged the survey team on Zulip to ask how firm that limit is: https://rust-lang.zulipchat.com/#narrow/stream/402479-t-community.2Frust-survey/topic/WG-Embedded.20Micro.20Survey/near/454277658

[jamesmunns]

Answer was "nah, you can ask more questions":

The main thing that takes time and effort are translations. As long as the survey is only in English, then it takes maybe half an hour to fill the questions into SurveyHero, and the rest is mostly automated - we give you a link, you spread it within your community, and then once the survey ends, we send you a PDF with the results. If you'd want some custom analyses (like we do for the annual survey), then that would of course take a bit more effort.

[jamesmunns]

CC @alevy - I wanted to loop you in to this discussion, to see if there were any questions you'd be interested in including for this, and to coordinate with you to circulate this survey with the tock-os ecosystem once we have it ready!

[alevy]

I think this is an excellent set of questions. Very happy to circulate among the Tock ecosystem.

I'm not sure how to articulate this exactly (and thus would also rank this very low priority for adding to questions), but would be good to ask something about the provenance of using Rust and using the specific tools they used. E.g. "my boss forced me", "I forced my boss," "read XYZ book/blog," "constrained due to XYZ engineering reasons."

[jamesmunns]

Moving tracking to #782

[jannic]

Triage team

@jessebraham and @jannic discussed ideas about how triaging should be handled. No finished proposal yet, but we tend to define some simple rules like:

• Wishlist issues, feature requests, implementation ideas, usability improvements etc. that didn't have
  any progress in 6 months should be labeled as STALE and should be discussed in a weekly meeting. Possible actions:
  • close them because of lacking progress
  • mark them as LONG TERM GOAL
    • these will be reassessed about every 6 months like other tickets without progress
• Verified bugs get the label BUG and should stay open until they are fixed or it's actively decided that they won't be fixed.
• For bug reports that can't be reproduced and where the author didn't provide additional information for 3 months
  should be closed as unreproducible. If in doubt, ping the author for additional information first.

The procedure described at https://forge.rust-lang.org/triage-procedure.html (and referenced by https://github.com/rust-embedded/wg/blob/master/rfcs/0136-teams.md) seems to be too complicated for our use case.

[adam-hott]

Is my proposal worthwhile to the Rust Community AND the Embedded Engineering Community?

https://github.com/adamhott/rust-spot-wg-proposal?tab=readme-ov-file

If so, would it be worth exploring submitting a more polished version for a Rust Foundation Grant?

[BartMassey]

The alpha draft of https://github.com/BartMassey-upstream/discovery-mb2 is now complete on the main branch. I still need to transfer the repo to rust-embedded, set up the CI, and make another couple of light editing passes.

As always, any advice or help appreciated: ping me on Matrix@bartmassey if you'd like to get involved.