T-spec meeting 2024-09-19

--- title: T-spec meeting 2024-09-19 tags: ["T-spec", "meeting", "minutes"] date: 2024-09-19 discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202024-09-19 url: https://hackmd.io/fJUBDqkDSpKFG57PRtigCQ --- Attendees: Joel Marcey, Connor Horman, Eric Huss, Pierre-Emmanuel Patry, Monadic Cat, pnkfelix, TC, Sid Askary Agenda * Naming Rule Identifiers * ABI PR * Revisiting Ferrocene ## Naming Rule Identifiers [Issue](https://github.com/rust-lang/reference/issues/1609) Connor: The pull request explains how the identifiers were added to the reference and how others can do it in the future. Connor: The pull request has been reviewed. There were a few comments on the PR. Connor: Need to be more specific more often. And the naming in particular of the requirement - what keywords should be used? In reference to: https://github.com/rust-lang/reference/pull/1609/files#r1764077789 (A lot of context for this discussion is in the comments of the pull request) The pull request to be merged moduluo some of the controversial keywords. ## ABI [PR](https://github.com/rust-lang/reference/pull/1545) Eric: Overall happy with the PR modulo some resolving review comments. Happy to merge after that. TC: agrees, just resolve the review comments. ## Revisiting Ferrocene TL;DR: **We need to seriously reconsider the Ferrocene specification.** ### Background After attending the first in-person meeting of the [Safety Critical Consortium](https://foundation.rust-lang.org/news/announcing-the-safety-critical-rust-consortium/), it has become clear that industry is hungry for a specification, right now. We have literally hit intersection between theory and pragmatics. Companies like Woven by Toyota, Volvo, Oxide OS and others are surprised by our direction on not using a Rust specification that was already available and developed with safety critical in mind. Ferrocene is first-to-market in the Rust specification space. And industry is gravitating towards that specification for use in their efforts to find a certified Rust toolchain for safety critical work. The Safety Critical Consortium meeting was held at the beginning of RustConf and there was plenty of conversation around it. Don't just take Joel's word for this. pnkfelix, for example, had a conversation with Florian that produced two distinct gaps that the `t-spec` team has readily acknowledged. 1. The `t-spec` team lacks representation from the industrial side of safety critical (e.g. people who have experience going through relevant software certifications). 2. Rust users today have already taken a bet on Ferrocene as the first-to-market, but we haven't really put any thought into how we are going to help those users transition or migrate from Ferrocene over to a different spec (or if the spec we deliver has to have some level of "compatibility" with Ferrocene. Joel is in the currently unique position of being part of both the `t-spec` team and the Safety Critical Consortium. So I have to wear two hats here. And my SCC hat says that if we have to go with Ferrocene in order to make progress on the work we want to accomplish within the consoritum, then we will do that. *And that would be a really bad look having two distinct Rust specifications.* I believe the Rust Project should be the source of truth for the Rust specification and we are in danger of not allowing that to happen. ### What can we do? We have an established decision-point, scheduled for October, where we are going to evaluate "do we believe we have both demonstrated progress and a roadmap to a final deliverable." The question becomes: *should we expand that scope to include Ferrocene compatibility and/or migration path?* If the answer is "yes", do we still believe that it is more efficient to attempt delivery atop the Rust Reference, rather than atop Ferrocene, given that constraint? Joel sees two options: 1. Adopt the Ferrocene specification right now, after a review to ensure there are no egregious errors (some mistakes are ok, but nothing massive), as the the spec of record and form a `t-spec next gen` team to continue the work of migrating the reference over to a specification and then prove to industry that the next gen spec is better (a superset) of the Ferrocene specification. 2. Continue the current plan but put a hard decision in October, with an honest assessment, saying whether or not we can have a Ferrocene-level spec by EoY. If so, we tell the SCC that we will have a spec of record by Jan 2025. If not, we adopt the Ferrocene spec right then and move back to option #1. *Question, particularly if we go with Option #1:* For `t-spec-next-gen`, will an explicit migration path or some kind of ferrocene-compatibility constraints be part of it? *Joel wants to reiterate - at some point very, very soon, a critical mass of safety critical folks are going to go with Ferrocene with or without us most likely and that would be a really bad look.* Connor: Don't they have to re-certify anyway in between iterations of the specification ? Joel: [...] Connor: alternate impl Joel: Missing mechanism TC: Two main thoughts here. 1) We should find out concretely what the concern is. When we say that companies are "investing in the FLS", what does that mean exactly? E.g., are companies producing large documents that carefully cite hundreds or thousands of specific bits of the FLS? Or are they treating it more as a black box? We should find out. 2) We should clarify what the new information is here. We knew of course that Ferrous' business was to serve this space and that they wrote the FLS in support of this. Joel: It is new information because now we do have some people telling us about it. TC: I had assumed that Ferrous Systems did this work because they had customers, so I'm not surprised to find they're attracting more. TC: The ask here -- that the project have a replacement solution in this space in about three months -- is a big ask. So we should have concrete knowledge to make decisions. TC: Similarly, before worrying about mapping citations between the FLS and the Reference, we should verify this is actually the problem that people have and not just guess or assume. Joel: [...] Connor: In terms of specification content we're relatively close between ferrocene and the current set of PRs that are up. We're not there but we're close. We're not too far off, any ressources put on one path would be needed on the other path. If their end goal is to have something similar to ferrocene we won't need lot of ressources [...] if the end goal is to have a complete specification we will need a lot of ressources either way. Eric: What do people actually want ? Joel: They want the rust project to have a specification. And they don't understand why we didn't go with FLS. Eric: We could point them to the reference Joel: We could but [...] Pnkfelix: Customers are using ferocene and it meets their need today. There's gaps we haven't filled but that we're hoping to fill. Ferrocene check all the boxes for them now. Even if we match FLS (in terms of checking all the same boxes that Ferrocene checks off), it doesn't address how such customers are actually expected to *migrate* from Ferrocene over to what we provide (unless we plan for that in advance). TC said "I don't know what are the gaps" but [...] Joel: I can bring someone from Oxyde Computer in the next meeting to answer that question. Eric: Sid: Conversation with people at rustconf, this group is isolated. To that extent it would be good to have representatives from the industry in this group. We should probably bring back ferrocene people to help answer some questions. Joel (in chat): I want to acknowledge that it would have been nice of Ferrous to work with the Project on the original concept of the Ferrocene specification. And maybe we would not be where we are today. So I don't hold them completely blameless here. Connor (in chat): I believe they did at least have some initial collaboration. There was a T-lang design meeting regarding the initial startup of it back in 2021 I want to say. Joel: I will work to get people in next meeting, might bring more confusion but I hope it'll work out Felix: To me, the critical question we must answer is: Is a migration path off Ferrocene and onto what we deliver *part of* what we have to deliver ? [...] Sid: Two spec solution is not possible for them Joel: And it should be managed by the project