Meeting 2026-05-05

[adamgreig]

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

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

The REWG Code of Conduct applies.

[thejpster]

Nico wants us to think about Battery Packs

https://battery-pack-rs.github.io/battery-pack/

Matrix comment

[thejpster]

The Rust Foundation have formed the Rust Commercial Network and would like Embedded to have a group there.

Basically it sounds like wg-embedded could be in both the Rust Society run by the Project and the RCN run by the Foundation.

https://github.com/Rust-Commercial-Network/rcn

Matrix comment

[AnthonyGrondin]

RFC: Discuss the acceptability of implementating a voucher system for contributors

Note

I want to preface this by saying this isn't a discussion about the use of AI-generated / LLM-assisted contributions. Although tightly related to recent developments in the open-source ecosystem, the proposed system is independent of the nature of contributions.

Rationale

Some open-source projects, like Ghostty, have started to implement a voucher system to prevent undesirable contributions and spam, and to easily block known bad actors while relying on a public list.

Recently, there has been an increase in contributions from first-time contributors across many Embedded Rust projects, often adding hundreds of lines of changes in obviously LLM-generated PRs or otherwise undesirable changes.^{1 2 3}

The intent of this proposal is to discuss the acceptability of adding a similar voucher system to prevent unwanted contributions and to vouch for known good contributors. For now, this issue is still manually manageable, but it could worsen in the future as Embedded Rust gains more traction and more people try to embellish their portfolios.

In the event that this proposal is received favorably, individual Embedded Rust projects / groups would remain free to decide how they want to implement such a system, if they choose to do so. That said, I would like to add my personal opinion that agreeing on a standard and workflow would allow for easier maintainability and sharing of vouched users.

Implementation

This RFC does not yet discuss HOW the system should be implemented, as acceptance of such a proposal is the initial step. Embedded Rust projects are community-led efforts involving many contributors, who may have differing views on the acceptability of such a system.

In contrast, the Ghostty project is largely driven by a single primary maintainer, allowing for more centralized decision-making. It is therefore referenced as an example of a system that appears well implemented.

Footnotes

1. A first-time contributor tried to add a link to a blockchain crypto project to collect a bounty ↩

2. An automated PR in esp-hal with unwanted noise from an AI agent ↩

3. PR closed for mainly AI-generated output and unnecessary maintainer burden ↩

[AnthonyGrondin]

Summary of the proposal after discussion.

Note

This summary has been generated with GPT 5.5 Thinking based on discussion inputs for deduplication and anonymization.

• Overall sentiment: cautious and mostly skeptical for now.
• Participants appreciated the detailed proposal and found the voucher-system idea interesting in principle.
• Several people felt the Rust Embedded WG does not currently have a serious enough problem with unwanted or low-quality contributions to justify this kind of system.
• A major concern was that a voucher requirement would add friction for first-time or one-time contributors, especially people fixing HAL/driver bugs or adding support for hardware they personally use.
• Contributors worried that the system could discourage beginners who are already intimidated by opening GitHub PRs.
• There was discomfort around the WG publishing or maintaining a list of “denounced” users that other projects might rely on.
• Some noted that the system makes more sense for projects that are overwhelmed with PRs and need stronger filtering.
• Implementation overhead was also a concern: automation, review processes, and maintenance would need to be justified by clear benefits.
• The rough consensus was: “good idea, but not for us today.”
• Final takeaway: the group was not opposed to the concept in general, but felt it would be premature and potentially harmful for the Rust Embedded ecosystem at its current stage.

I thank everyone for their provided point of views and further thinking on this topic. 🫶

[jannic]

Triage

rust-embedded/qemu-exit#36 asks for a new release, and from the list of PRs that should be merged before such a release, rust-embedded/qemu-exit#40 is the only one not yet merged. Simple change, likely not controversial. Could be improved by some safety comments, but I don't think that's critical.

[adamgreig]

Suggestion made for safety comments for the new methods, then we can merge and release.

[adamgreig]

aarch32-cpu and aarch32-rt both released at 0.3 🎉