Safety-Critical-Rust-Consortium
diff --git a/‎meetings/2025-10-14 - 2025-10-15/2025-10-14-minutes.md‎
Lines changed: 210 additions & 0 deletions b/‎meetings/2025-10-14 - 2025-10-15/2025-10-14-minutes.md‎
Lines changed: 210 additions & 0 deletions
@@ -0,0 +1,210 @@
+# 2025 Late Year Global Virtual Meetup \- Day 1 \- 2025-10-14 @ Oct 14, 2025 9:00 AM
+
+| Search Key | Description |
+| :---- | :---- |
+| \[todo\] | Action Item |
+| \[decision\] | Something decided on |
+| \[important\] | Key information |
+
+## Agenda
+
+| Time | Topic | Person | Slide |
+| :---- | :---- | :---- | :---- |
+| 9:05 AM EDT \- 9:15 AM EDT | Agenda introduction for day 1 and 2 | Pete LeVasseur | 3 |
+| 9:15 AM EDT \- 10:00 AM EDT | Retrospective, reaffirming our values, RFC process | Joel & Pete | 5 |
+| 10:00 AM EDT- 10:15 AM EDT | FLS Team | Pete LeVasseur | 28 |
+| 10:15 AM EDT \- 10:30 AM EDT | Break time |  | 30 |
+| 10:30 AM EDT \- 11:00 AM EDT | Funding of in-person events and swag expenses | Pete LeVasseur | 31 |
+| 11:00 AM EDT \- 11:20 AM EDT | Liaison Subcommittee | Alex Celeste | 37 |
+| 11:20 AM EDT \- 11:40 AM EDT | Tooling Subcommittee | Alexandru Radovici | 43 |
+| 11:40 AM EDT \- 11:55 AM EDT | Coding Guidelines Subcommittee | Pete LeVasseur | xx |
+| 11:55 AM EDT \- 12:00 PM EDT | Meeting close | Pete LeVasseur | xx |
+
+## Pete needs to have alternative emails added for the following
+
+* Tshepang (have the email, need to add to the Consortium mailing list)  
+* Tiago  
+* David Wood (*usual.salt4489@fuligin.ink* is the email I use for Google, already on mailing list)  
+* Julius (have the email, need to add to Consortium mailing list)  
+* Gideon (have the email, need to add to to the Consortium mailing list)  
+* Satoshi Kaneko  
+* Markus Hosch (markus.hosch@gmx.net)  
+* Christof Petig (I registered [christof.petig@aptiv.com](mailto:christof.petig@aptiv.com) and use my @[gmail.com](http://gmail.com) address for google login, [Issue \#480](https://github.com/rustfoundation/safety-critical-rust-consortium/issues/480))
+
+## Items for open discussion tomorrow
+
+* 
+
+## Check-in area
+
+**Please add your name, and an emoji that describes your day.**
+
+* Pete LeVasseur 🦀💬  
+* David Svoboda ;}  
+* Daniel Szucs 🚀  
+* Florian Gilcher 😃👷  
+* Alex Celeste ☕  
+* Félix Fischer ☕  
+* Tshepang 😶  
+* Tiago Manczak ☕  
+* Tony Aiello 😀  
+* William Barsse   
+* Samuel Wright 🌞  
+* David Wood 🦀  
+* Alexandru Radovici 😀  
+* Oreste Bernardi⛰️  
+* Christof Petig ⌚  
+* Manuel Hatzl 🍕  
+* Julius Gustavsson 🙂  
+* Rinat Shigapov 👶  
+* Mikhail Antoshkin 🦀  
+* Satoshi Kaneko 🙂  
+* Daniel Krippner 👍  
+* Joel Marcey 🥱  
+* Gideon Mueller   
+* John Vishnefske 🚀  
+* Max Jacinto 🍀  
+* Robert C. Seacord 😵‍💫  
+* Markus Hosch 👾  
+* Xander Cesari 🤒
+
+**Notetaker (before break):**
+
+* David Svoboda 
+
+**Notetaker (after break):**
+
+* Félix Fischer
+
+## Meeting Minutes
+
+* Introduction of participants, review of the agenda: today’s meeting is more report-oriented with detail for tomorrow  
+  * Day 2’s agenda has intentional open spaces to fill in as matters arise  
+* Retrospective, reaffirming our values, RFC process  
+  * Q: What do we mean by 'non-differentiating portions of the ecosystem"?  
+    * A: If you have a closed-source ecosystem independent of Rust, the differentiating piece (for different languages). Non-differentiating pieces aren't specific to Rust. Rust prefers non-differentiating features that help multiple languages, not just Rust.  
+  * We have a community grants program, for providing resources for people to do work. Also the [Rust Innovation Lab](https://rustfoundation.org/rust-innovation-lab/), which can support/fund projects. Also directed funding for specific things.  
+  * Q: By "values", you refer to 'technical values" right?  
+    * A: Right. These are not binding but are things we would like to see to help Rust succeed.  
+  * Concern that splitting the team between contributors and observers will be too simplistic.  
+    * Anyone can submit a coding guidelines issue. As part of the team, you are doing something, perhaps triaging pull requests. Contributors may have a rotation of reviews for guidelines.  
+    * [PR 149](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/pull/149) has a [diagram](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/blob/d20616f257e0f30271e95409e1acaf14cb30c0b4/CONTRIBUTING.md#diagram-for-contribution-workflow) for contributing to coding guidelines. (It hasn't been merged yet).
+  * Perhaps this already exists: We might need a "0th RFC" that writes down how things work at the moment. Ground truth for current processes.  
+* FLS Team  
+  * Q: What does "non-binding but normative" mean regarding FLS and the Rust compiler?  
+    * A: The Rust reference is the way the compiler should work, but the canonical implementation may have bugs. There is a reconciliation process between compiler reference and FLS. Someday the docs will be in agreement, perhaps unified, and the compiler will comply.  
+    * If something in the spec is unsound or incorrect, the FLS conclusions will eventually direct behavior of the compiler, as opposed to the compiler directing the FLS.  
+  * Q: There exists a document that describes behavior of safety-critical software. Who is right?  
+    * A: This is still an active area in the Rust Specification Team. Maybe the Rust reference should be more nightly (e.g. what is available in nightly builds), and serve the needs of folks more broadly using Rust. And the FLS evolves into a snapshot of the compiler behavior at a stable release. This seems to be the direction of the specification team.  
+    * We need a 'correct' spec that describes behavior of the compiler with each release. The Rust compiler has a nightly version and \~4000 RFC's. Many are rejected. The spec is an attempt to figure out the RFC's that are adopted. All behavior is covered by tests.  
+    * Some RFC's have only been partially implemented, such as the const generics RFC ([2000](https://github.com/rust-lang/rust/issues/44580)). Very hard to complete.  
+* (break)  
+* 2026 Rust All-Hands  
+  * Our Q2 event for next year?  
+  * Q: Regarding funding for attending the meetups: is there any chance for partial support between the different organizations (eg the Rust Foundation and another org splitting the cost of funding, etc)  
+    * A1: there has been talks regarding this, nothing very concrete. Preliminary conversations point to it being a bit of a hassle. But again, nothing concrete yet.  
+    * Bonus: The Foundation is wondering whether there is a fairer way to fund these things / a better model.  
+    * A2 (from another contributor): what is working currently is that their organization pays for it  
+    * A3 (another contributor): ISO doesn’t provide its committees with any funding, but it helps them with infrastructure  
+    * A4 (idem): “we currently latch on to Rust conferences to do our meetups (see: All-Hands in Utrecht in May 2025)”. This helps because it spreads the fixed costs of travel between multiple activities. On the other hand, the Rust conferences don’t have a consistent / established cadence or schedule, so it’s a bit inconsistent for now in that format.  
+* Swag Expenses  
+  * How to make them sustainable?  
+    * A1: we’ve shared the designs (in our other committee), in a way such that you can upload designs to a sticker printer, and if anyone wants to get some, they can  
+    * A2: reimbursing the costs with your company is usually a waste of labor \- it’s best to just fund swag in some other way  
+    * A3: manufacturing stickers and such is almost pure fixed cost \- making them en masse is way cheaper per sticker.  
+    * Bonus A: “making the assets available is an instant win without any drawbacks” 🙂  
+* Liaison Subcommittee  
+  * Expert Sessions  
+    * 40-50 attendants for Jill Britton’s talk  
+      * Folks seem to know the basics of the pipeline now, that’s great\!  
+      * [Final minutes here](https://github.com/rustfoundation/safety-critical-rust-consortium/blob/main/subcommittee/liaison/meetings/2025-10-02/minutes.md)  
+    * Requests  
+      * For a talk on the role of a lang standard or spec in certified development  
+      * Tentative:  
+        * Software “quality” metrics?  
+        * Integration of adopted code?  
+      * **If you have questions**:  
+        * DM Alex Celeste on Zulip or email or Github.  
+        * Raising questions in a public space is better \- that’s preferred since different folks might have the same questions  
+  * ISO WG23  
+    * The WG has agreed to start work on a Rust base document  
+      * The WG doesn’t feel like they have any fluent enough Rust experts.  
+      * **Call is out for experts from our group\!**  
+        * Alex currently has 1-2 volunteers from the Rust SC committee.  
+        * Getting to about 4-5 would be a good amount.  
+          The more the merrier, though\!  
+        * **We may want a new SC subcommittee**  
+          * Concerns were raised w.r.t. making such a subcommittee: it was done (sort of) for C and the C folks mostly quit it. Yet the WG found someone who wanted to work on it and it’s... currently a bit awkward.  
+          * Or perhaps a sub sub committee owned by the Guidelines subcommittee  
+    * Do not fret: the WG does not require an ISO standard to exist for the languages they work in (their Python work stands as precedent)  
+  * MISRA  
+    * Still considering a publication in this space  
+  * WG21 / C++  
+    * Continues to collaborate w.r.t. C++’s ABI
+      * Interop with this ABI is not trivial
+      * The work is centered around the [Rust-C++ Interoperability Initiative](https://rustfoundation.org/interop-initiative)
+    * Work is nascent for now.  
+* Tooling Subcommittee  
+  * Goal: figure out what tools exist today, and how to push the ecosystem further  
+  * Split in two task forces:  
+    * Rust Project Bridge:  
+      * Facilitate connection to the Rust Project  
+      * Raise awareness  
+    * Tool review:  
+      * Review tools and compile a list of tools  
+  * Actions:  
+    * Manual on how to contribute to the Rust Project  
+    * Identify and Monitor features that the SC community requires  
+    * Talk to the Rust Project about SC and the overlap between SC needs and the Rust Compiler  
+  *  Folks raising their hand:  
+    * David Wood offers their help from the Rust Project side  
+    * It was suggested that a concrete priority list of specific Safety Critical features should be provided to the Rust Project.  
+    * There seems to be a lot of overlap between the Rust Project’s goals and the SC goals. A “bridge” of sorts is being constructed  
+  * Tool Review  
+    * In the next Subcommittee meeting, the list of submitted tools will be reviewed and a preliminary list will be published  
+    * For the beginning, the bar needs to be low.  
+      * The criteria will evolve from this and is expected to become concrete and more strict over time.  
+    * Relevant PR: [\#463](https://github.com/rustfoundation/safety-critical-rust-consortium/pull/463)  
+* Coding Guidelines Subcommittee  
+  * Foundations:  
+    * Subset v/s Defects  
+    * Categorization, e.g. Mandatory v/s Required  
+  * Infrastructure Setup  
+    * Many important bits have been configured  
+    * A few loose ends yet to figure out before soliciting wider contributions  
+      * Multiple examples per guideline,  
+      * CI/CD work to help review and testing of e.g. code snippets  
+      * Generation of Sphinx source from Guideline Issues still has a few rough edges  
+  * Tentative Roadmap  
+    * v0.1.0  
+      * (Porting subsets of)  
+        * CERT C  
+        * MISRA C  
+      * Finding useable lints from Clippy and the Compiler for our use-cases  
+        * Finding out what SC rules they map to  
+      * **Subset out** unaddressed language constructs  
+      * Final audit  
+        * (Not present in the diagram draft yet\!)  
+        * Producers take “status-draft” guidelines and graduate them to “status-approved” guidelines  
+        * Important criteria:  
+          * **Incompleteness is fine**  
+          * **It’s best to be “correct”** (read: logically consistent). Any set of guidelines, as long as it is correct, is good.  
+            * Completeness is a good thing, but it’s completely secondary when compared to correctness  
+    * v0.2.0  
+      * A few (say, 10-15) guidelines per chapter  
+      * Subset out unaddressed language constructs  
+      * Final audit: same as v0.1.0  
+    * v0.3.0  
+      * Thorough review by producers and observers (as desired)  
+      * Request for comment from entire Consortium membership  
+      * Final audit: same as v0.1.0  
+    * v1.0.0  
+      * Tracing to individual industry safety-critical standards per guideline  
+        * An audience member advised against this due to historical experience with C safety-critical standards  
+      * Receive 3+ reports of the coding guidelines having been used in SC products or projects  
+  * Producers and Observers  
+    * We want to make expectations clearer of what each role means and what rights and responsibilities everyone has.  
+      * Defining e.g. reviewer rotation  
+      * Not effective immediately but it’s on the horizon  
+        * Expect this to go into effect sometime late this year or early 2026
+