---
date: 2025-10-31
url: https://hackmd.io/529QeGklTb-X64UPnguyLA
---

# 2025-10-31 - `t-fls` Meeting

## Attendance

### Attendees

- Pete LeVasseur, Eric Huss, Hristian Kirtchev, TC, Tomas Sedovic, Tshepang Mbambo

### Regrets

- Alex Celeste

## Agenda

- Welcome! Brief intros, say ~3 minute apiece
- t-fls and t-fls-contributors
- Standing up the GitHub repo - [fls-team](https://github.com/rust-lang/fls-team)
- posting our minutes there
- adding a way of work with content akin to [FLS Team - North Star](https://hackmd.io/@plevasseur/HJb6qomOge)
- Initial effort - finish 1.90 release
- Initial reading
- begin with glossary
- expand to reading chapters
- Initial goal - FLS for 1.91.0 as a team
- better to try now rather than wait until "ready"?
- Discuss how to break down new stable compiler release contents
- GitHub issues to allow work to be distributed, possibly
- Discuss how to triage and do intake on improvements to FLS
- some GitHub automation stuff may be useful and prioritization
- Pete unable to attend next instance; could we have a volunteer to 1. build the agenda and 2. run the meeting?
- <= triage line =>
- Discuss [Tshepang's notes](https://rust-lang.zulipchat.com/#narrow/channel/520710-t-lang.2Ffls/topic/2025-10-31.20meet/near/547679956)
- Discuss [Hristian's notes](https://rust-lang.zulipchat.com/#narrow/channel/520710-t-lang.2Ffls/topic/Hristian's.20notes/with/547716506)

## Minutes

### Welcome! Brief intros, say ~3 minute apiece

Hristian ("ha-ris-tian"): I work with AdaCore. One of the original FLS editors. Nice to be back at it.

Eric Huss: Been around the Rust project since 2018.

Pete: Eric's been an awesome job of maintaining the Rust Reference, making sure it's up-to-date.

TC: I work with Eric on maintaining the Reference. In doing that, one learns a lot about the document and thinks a lot about what it means to specify Rust, the boundaries of the specification, etc. I'm on Lang team, Council, and other teams. I joined this team mostly as in a liaison capacity. I have to be honest that I don't have the bandwidth to allow myself to care as much about the FLS as I do about the Reference. But I care about specifying Rust broadly and I care about developing a productive interaction between the FLS and the Reference. It's particularly exciting that with this team we've been able to bring in new Project members; it's always great when we can stand up a new team and bring in new energy. I'm happy to support the team in any way I can; if it needs anything from the Project or needs some problem removed from its path, that's what I tend to be good at.

Pete: The way we've framed this in our other collaborations is that TC handles the back-of-the-house operations, which he does well, and I handle the front-of-house operations.

Tomas: I was hired by the Project as a program manager since June. I help teams with various things and take minutes. I'm on the spec team calls and it made sense to help out here as well.

Pete: I've been in the automotive industry for 12-ish years. Worked at OEM, GM. My background is in automatic driving. I wrote a lot of C++, always wanted to bring Rust in. Working at Woven Toyota to be able to expand Rust to the industry. I lead Safety Critical Rust Consortium. I chair the Coding Guidelines group. We'll put in some time to make sure the FLS is a good document.

Tsepang: I work on the FLS for Ferrous Systems. Been a member of the Rust Project for a while. Mainly the Rust compiler dev-guide.

### t-fls and t-fls-contributors

Pete: There are two teems being created: t-fls and t-fls-contributors. `t-fls` puts thought on how the document should evolve, how it aligns with the Reference. t-fls-contributors: folks interested and have stake in making sure Rust is suitable for safety critical. Increasing alignment with the Reference, ensure Rust continues to be useful in the domain. I want to add people to fls-contributors. If you notice someone being active, opening issues, opening up PRs let's talk to them. If we get the feeling they're invested and involved over time, we may want to bring them in.

### Initial effort - finish 1.90 release

Pete: This is our [github repo](https://github.com/rust-lang/fls-team). I'll flesh it out more. How we would like to work, how to make the FLS updating process sustainable. Document to be helpful for the entire safety critical community. Not to overload any single person. Tomas will be posting meeting minutes.

### Initial reading

Pete: We were discussing the FLS yesterday at the spec call. We've realised 1.90 version of the FLS has not been released yet. We should work on that. TC recommended I start reading the glossary to have enough context. I'm about 1/10th of the way through. Let's have a reading circle, devote a bit of time each week to get familiar with the glossary and discuss. Let's bring the base level of understanding up for everyone.

Hristian: For the FLS releases, we always lag behind the Rust releases. Is the intent to be on par with Rust releases eventually?

Pete: I'd like for us to get there. When we all get more familiar, we can better keep track of the Reference, feature, compiler PRs. And within maybe a couple days of the compiler we can do the FLS release. It'll be a ramp-up though.

Pete: Once we got the initial effort out, let's look at the 1.91, get that documented. Once we've done that we can think about the other releases.

### Discuss how to break down new stable compiler release contents

Pete: Maybe we rotate on someone going over the release notes. Once that's done folks can look at the issues, pick them up and work on them. We can distribute the work that way. By rotating the breakdown and issue creation can help everyone understand different parts of the compiler and the language. Thoughts?

Hristian: Sounds reasonable to me.

Tsepang: +1.

Pete: What can we learn from the Reference on this?

TC: The Reference is different -- we're integrated into the feature process. The PRs to the Reference come in before stabilization. For the FLS, I might suggest we could break things down further than the level of each release and look at the Reference PRs as they come in for stabilization. Most of those things will need to migrate to the FLS. Letting the Reference process play out, and getting involved in that process, would benefit the FLS -- figuring out the correct statement of the behavior, writing out tests, etc. We work with the author to make that crisp and clear. If FLS team is following along, and participating, at the end of that process the FLS team will be in a good position to take that understanding and that text and to translate it to the FLS by virtue of being embedded in the process.

Pete: That's a great idea. We're playing catch-up now, but going forward, looking at the relevant next Rust compiler release we could have someone from FLS attached and monitor it and understand it well enough to be able to draft the FLS PR.

TC: Yes, that's roughly what I was thinking. There's a lot of good work going on. Following and participating in that early is going to be helpful. Eric -- thank you again for joining us -- what would you add?

Eric: I was thinking how to make this process as smooth as possible from tooling perspective. There will be Reference PRs that won't be as relevant. How can the FLS team digest that information in an efficient way? We have tooling that can auto-milestone PRs when they're merged. We talked about having a changelog like the FLS -- would that be valuable? What ideas do you have to make sure you're getting the right information?

Pete: Can you tell me more about the auto-milestoning?

Eric: We don't have it in Reference but we do have it in other repos. When changes get upstreamed in a Rust release, they get an automatic milestone. That will show you which release the change got in. That won't help you before the release is made -- because we don't know which release a change will be in ahead of time.

Pete: So a PR can be open for some time for something that's in nightly, is that correct?

Eric: We have an open PR in rust-lang/rust and a PR in the reference simultaneously. Once they're both ready, the rust-lang/rust PR is merged (into nightly) first, then the Reference PR is merged.

Pete: Ah, so there's a stable, beta and nightly version of the Reference, right?

Eric: What lands in the master of the Reference, it goes into nightly. 6 weeks later into beta etc.

Hristian: Is it possible a feature lands in the compiler but a change lands in the next beta?

Eric: It is possible but we try to avoid it. It takes 2-3 days to get into beta. If that delay happens during beta branches we backport it.

Pete: When we say that a PR gets merged into the compiler for nightly, that doesn't guarantee the feature will get into beta in any certain timeframe. Do you merge the Reference PR then?

Eric: When the feature stabilizes and merges into nightly, we wait 24h for the nightly to publish so that the tests pass, then we merge the Reference PR. And then there's a bit of delay to merge into the rust-lang/rust repo.

Pete: Right, it is the stabilization PRs that trigger the Reference PR to merge. Other PRs won't cause the Reference PR to be merged.

Eric: That's correct.

Pete: We should start monitoring Reference PRs that seem close to merging. Is that something Eric or TC have a better sense about? Can you tag us on PRs that seem likely they'll be coming up in the next release? That might help bootstrap us.

Eric: That definitely sounds doable to me. TC as part of the Lang team knows more about what's imminent. That would be a good thing to do. And going forward we could think about using tooling or other processes to help people out.

TC: Sometimes it's hard to say; often one just has to watch.

Eric: We can try our best to find the right time to keep you informed.

Pete: Any help is big help at this point. Maybe picking a couple that might be coming that seem relevant would be great.

Tsepang: What advantage do you see for us to PRs that weren't stabilized yet?

TC: Many learnings happen during the process of getting these PRs ready to merge. Reviews are dynamic, and looking at it later is probably harder than following along. Either way, the important part is understanding what is learned, e.g., why something can't be described more simply, so that this process doesn't have to happen again on the FLS side.

Tsepang: It's purely for the learning cost? Is there a desire to document something before it's stabilized?

TC: Only after it's stabilized, under current process, does it go into the Reference.

Eric: It would be great to have more people involved in the process. If you are looking at a stabilization PR and you don't understand it, that's an issue. You can chime in during the process that it's hard to understand -- and we can take that signal to improve it.

TC: Yes, one primary purpose of Reference reviews is to get language that's as clear and understandable as it can be. A lot of PRs, originally, don't make a lot of sense to Eric and I -- and we're fairly plugged in. If something doesn't make sense to us, that's a signal that it won't make sense to most other people. Your perspective will help us in a similar way. If something doesn't make sense to you, that's a really helpful signal to us.

Hristian: If we can't understand the feature or the description is ambiguous -- do we have access to language authors to sit down and discuss?

TC: That's a good reason to get involved. The implementer is usually the person submitting the PR to the Reference. By asking there, you get the response from the implementer.

Eric: When you have questions on who's expert on something, we can connect you to that person. If you look at the stabilization PR, that has the stabilization report that describes what's being stabilized. If that's not clear to you, chime in on github and ask questions.

Tomas: Shift left is a good reason for us to engage earlier on in the Reference PR process. Mostly captured by what was shared by TC and Eric above.

Tsepang: If we watch the Reference we'll put less effort on TC and Eric.

TC: When you see a PR coming into the Reference, for a language chance, it's typically because someone's interested in pushing a stabilization. The Reference PR will have a link to the tracking issue and the stabilization. If you click through, you'll see whether that's moving or not, e.g., if from the lang side we've proposed it for "FCP merge", it's getting checkboxes, etc.

The way the stabilization process proceeds, after someone puts up a stabilization PR, is that someone on the team proposes the PR for FCP merge and members start checking their boxes. Once the majority and no less than all the members minus two check their boxes, it move to the final comment period (FCP). During that time, if no-one raises a concern, the change is accepted and can be merged. So from the FLS side, as you see FCP boxes getting checked and no concerns being raise, you can see the approximate timeline of when it's going to land. Similarly, as it's moving along, we get more interested in the Reference PR.

Pete: As things start to get close to stabilization, how do you handle the process / stress?

TC: In terms of getting the Reference PR in the same release? That's why we block landing the language change on the Reference PR being ready. Otherwise it would not be sustainable while maintaining the expectation that the language in the Reference for a given version aligns with what's in the compiler for that version.

Without this, something could merge the day of the beta cut, and then we'd be on the clock to land and backport the Reference changes before the stable release. That would not be workable.

We could accept that the Reference would lag `rustc`, and that would be sustainable, but that would have other tradeoffs.

Pete: Has it always been this way?

TC: This goes back to at least 2017 when Niko stated this process in an issue and blocked a stabilization on a Reference update. But it wasn't handled consistently until recently. We've been doing it more consistently in the last 18 months.

Eric: When I started, the intent was that the documentation was ready before stabilization but it was loosely followed. There were also large gaps not written down. I tried to push on the lang team for many years to follow that process. It's been difficult -- putting more barriers into a process slows it down and people get frustrated. But it's really important we have clear specification of what we're stabilizing. Lots of mistakes and warts happened in the past due to lack of understanding of what was being stabilized.

Pete: Makes sense, thank you for that.

---

Pete: I'll add a github issue template for people to submit improvements to the FLS. Having traceability like that will be beneficial. Dropdown for the chapter, entry field for the FLS IDs. That'll help us catch issues more effectively. Any thoughts on this?

Hristian: Do it; it's good.

---

Pete: I'll be on the business trip for the next instance of the meeting. Can someone volunteer to build the agenda next time and run the meeting?

TC: I can handle the logistics if we work on the agenda together.

---

TC: With respect of templates, most projects in the Project use the same labels as rust-lang/rust (waiting-on-author, waiting-on-review). It's worth aligning on those labels.

### Roundtable discussion

TC: The 1.90 changes have not been merged yet. Tsepang made some changes we all need to review.

Prior to 1.89, I was just looking at whatever Tshepang sent in and making sure nothing was clearly wrong. For 1.89 and 1.90, as an experiment, I've tried holding these to the same standard as I'd hold for the Reference.

For 1.90, in particular, the language change touches on a place where the framing in the FLS is rather mistaken. To the extent it was achieving the right outcome, it was doing it for the wrong reasons. Simply removing the rule that's being removed in the language, then, ends up breaking the FLS a bit. Making it actually correct is going to take some work. I'd appreciate others having a look.

Tsepang: I'm glad we have Hristian in the room -- he was involved quite early in the FLS. I'm missing how much detail do we get into the behavior. In the past the Reference goes deep while the FLS has a lot of missing detail. I'd love to hear your comment.

Hristian: The two of us should definitely meet. When we were writing the FLS we invented a lot of the stuff. Let's meet and discuss. I'm planning to go through the changelog in depth.

Tsepang: Should we make it part of a regular meeting?

Pete: May be worth it being a part of our regular meeting yeah.

(The meeting ended here.)

---

### Initial goal - FLS for 1.91.0 as a team

### Discuss Tshepang's notes

### Discuss Hristian's notes