--- title: T-spec meeting 2025-02-27 tags: ["T-spec", "meeting", "minutes"] date: 2025-02-27 discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202025-02-27 url: https://hackmd.io/nS0Fxax2RpeetBIgZo4tlQ --- Attendees: - Joel Marcey, Pierre-Emmanuel Patry, Mara, Felix Gilcher, Sid Askary, Eric Huss, TC, nikomatsakis Agenda: - FLS Integration Update (Joel Marcey) - FLS Publication Project Goal Status (Joel Marcey) ## FLS Integration Update Joel: Publicly announced at the Safety Critical Rust Consortium meeting that the FLS will be transferred and integrated into the Project officially. Felix: Went through a set of technical details about how the integration would happen. Ferrous is documenting this for us as a team and the project. Will share with the `t-spec` team. Joel: There will be a transition period, Ferrous will continue their work on the FLS during that process. Felix: Expects that it will be 6-12 months of a transition period where Ferrous will continue working on the spec to be in line with the current state of the compiler. Will contribute anything back upstream. Felix: Will continue maintaing a fork for various business reasons. Felix: Expect the scope of the FLS to go beyond their current requirements, right now the FLS has some requirements tied to a given compiler version (tied to qualification of a given compiler), the rust project probably requires a broader scope. Sid: Do you have a link to the technical requirements. Felix: Not yet. It's internal. But will share. Niko: What does Ferrous see after the 6-12 months transition period? Felix: Hopefully will be able to avoid the drag. If `t-spec` only sits and waits for Ferrous PRs, not a lot of value. Happy to contribute work, but don't want to have a bunch of extra effort. Felix: There need to be some buy ins from the project to the spec. Joel: Hopefully we will reach a point where Ferrous doesn't have to contribute continuously, ferrous would become a regular contributor. TC: Felix, you mentioned you might still need to maintain a downstream fork if certain things happened upstream. What might cause the spec to no longer be useful to you and hence prompt a fork? Felix: for example we make sure the connection between the spec and test continues to exist. I could theoretically imagine that this is too much drag and we don't want to provide that linkage. I think it would be a loss but I could also see why one might do that. NM: It's good to know that is a possibility but also I hope we don't get to that, it would mean the spec is not meeting one of its goals, to be of value to the safety critical community. TC: What's the role of folks like Lukas who are both part of the project and Ferrous Systems during the transition? Are they likely to be maintainers of the FLS spec on the project side? Felix: From a practical reality, a lot of the work will continue to be done by us in the beginning, what I'd like to avoid is, as I mentioned earlier, that Ferrous "self reviews" its contributions to upstream. I'd like to avoid that because it gives the perception of Ferrous controlling the spec. NM: I think that's a sensible ask. We have to parcel that work out but it makes a lot of sense. Felix: Starting out with reviewing and approving the work should be comparatively easy to setup. Also a good way to ease into writing parts of the spec. Then there's the whole topic of how we integrate the reference into one format. ## FLS Publication Project Goal Status https://rust-lang.github.io/rust-project-goals/2025h1/spec-fls-publish.html https://github.com/rust-lang/rust-project-goals/issues/265