Meeting 2024-10-01

[jamesmunns]

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
• Nominated issues
• IRC/Matrix logs

Announcements

• Next book sprint for the Discovery MB2 book will be on October 26, 17:00-21:00 CEST, 15:00-19:00 UTC, 8:00AM-12:00PM PST. Join if you're interested in helping to write the new discovery book! Give a thumbs up to this comment to express your interest in joining.

Carry over from last week:

There are three larger topics we should schedule some time for:

1. The discussion regarding the CS Mutex, and whether it needs an inner UnsafeCell. Context: Why UnsafeCell in Mutex? critical-section#52 - we might need HAL team folks present.
2. We should follow up with discussing potential project goal proposals: Consider collecting proposals for 2024H2 Rust Project Goals #775 - relevant to whole WG
3. Discussion re: MMIO references. Context: Tracking/discussion issue for MMIO references #791 - we might also need the HAL team present

[jamesmunns]

CC @rust-embedded/hal - would y'all be able to be present/active in the meeting next week? There are two items above that are relevant and might be good to push forward.

[eldruin]

I will not be able to participate next week.

[jannic]

Another carry over from the week before: Is there anything blocking a cortex-m-rt release? rust-embedded/cortex-m#533

[hdoordt]

Announcement: next book sprint for the Discovery MB2 book will be on October 26, 17:00-21:00 CEST, 15:00-19:00 UTC, 8:00AM-12:00PM PST. Join if you're interested in helping to write the new discovery book!

If you're interested in joining, you can make that clear by liking this message.

[BartMassey]

EuroRust will be happening on 10-08 and GOSIM Beijing will be happening on 10-15. I suspect a lot of us will be at one or the other. Shall we meet on Matrix those weeks? If so, who can run these meetings?

[jamesmunns]

I'll be available, and I think @adamgreig will be back as well. If anyone thinks we should skip I'm open, otherwise I think we'll have hands to manage it!

[rursprung]

how to deal with long-term 0.x dependencies (defmt, heapless, etc.)?

as per the API guideline C-STABLE a crate should only publish a stable release if all public dependencies are also stable. in the embedded rust ecosystem this is a bit hard since some core crates are not yet on 1.0 (e.g. knurling-rs/defmt#795 & rust-embedded/heapless#410).

does anyone know if these crates will soon(-ish) reach v1.0?
if not: are there general guidelines on how to deal with this? e.g. is it generally accepted if you e.g. do an 1.0 release as long as these 0.x dependencies are optional and you add a statement to this regard to the README (excluding them from usual semver guarantees, i.e. you can bump from 0.x to 0.y of an optional dependency in a minor release of your own crate)?

this comes from here, where i'm wondering whether i should release this as v0.3.0 (and wait indefinitely with 1.0 until all dependencies are on 1.0) or just go with v1.0 with a semver exclusion disclaimer: rust-embedded-community/adafruit-bluefruit-protocol-rs#38 (in other news: any reviewers for this PR? 😉)