Skip to content

Update champion for FLS 2025H2 and add solicitation of stakeholders #372

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 17 additions & 7 deletions src/2025h2/FLS-up-to-date-capabilities.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

| Metadata | |
|:-----------------|----------------------------------------------------------------------------------|
| Point of contact | @JoelMarcey |
| Point of contact | @PLeVasseur |
| Status | Proposed |
| Tracking issue | |
| Zulip channel | #t-spec |
Expand All @@ -20,24 +20,32 @@ The target audience here will be those that have a vested interest in Rust speci

Keeping up with documentation is not always the most glamorous role for any project. And folks like @ehuss and others are doing an outstanding job at trying to keep the Reference current with actual code behavior. This is a hard job just for one document like the Reference. It will be even more difficult adding another core document like the FLS. But that doesn't necessarily mean we can't keep the FLS as up to date as is needed by its users.

### Solicitation of stakeholder involvement

The FLS is an enabler document for safety-qualifying versions of the Rust compiler. The safety-critical community of Rust users actively and passively benefit from the FLS.

Active users of the FLS should be consulted on changes with a "do no harm" approach taken to ensure the capability to use the FLS for safety-qualification of the Rust compiler is not disrupted. Active users consulted and contributing to maintenance will ensure the ability to achieve safety-qualification from an assessor.

Passive beneficiaries of the FLS becoming involved with maintenance and enrichment of the FLS supports the capability to have safety-qualified Rust compilers. Safety-qualified Rust compilers is a prerequisite for certain levels of safety-criticality in certain industries. These passive beneficiaries contributing back to the ability to ship safety-critical Rust software is a healthy model to ensure continuity of FLS maintenance.

### The next 6 months

Explore options for developing the capability to keep the FLS updated with the Rust language, in a sustainable way, at the cadence needed by its users.
Explore options for developing the capability to keep the FLS updated with the Rust language, in a sustainable way, at the cadence needed by its users and stakeholders.

The outcome of the next six months is variable. The entire six months could be investigative, with some prototyping. Or we could establish a concrete cadence and capacity for updating the FLS.

### The "shiny future" we are working towards

The shiny future we are working towards is to ensure that we have the capability in place to keep the FLS updated at the pace needed by its users.
The shiny future we are working towards is to ensure that we have the capability in place to keep the FLS updated at the pace needed by its users and stakeholders.

## Ownership and team asks

**Owner:** @JoelMarcey, in his capacity of `t-spec` team member will lead this project goal.
**Owner:** @PLeVasseur will champion this project goal.

| Task | Owner(s) or team(s) | Notes |
|------------------------------------|--------------------------------|---------------------------------|
| Discussion and moral support | ![Team][] [spec], [lang] | |
| Adjust tooling, as needed | @JoelMarcey | Joel to find appropriate person |
| Adjust tooling, as needed | @PLeVasseur | Pete to find appropriate person |
| Standard reviews | ![Team][] [lang],[opsem], [types], [bootstrap] | For any process changes, document updates and/or tooling integration |
| Continued updates for the FLS | Contributors from Ferrous Systems and others TBD | |
| Review of updates to the FLS | `t-spec` and contributors from Ferrous Systems | |
Expand All @@ -46,16 +54,18 @@ The shiny future we are working towards is to ensure that we have the capability

### Why this Project goal?

The goal is to ensure the FLS is updated sufficiently to meet the needs of its users.
The goal is to ensure the FLS is updated sufficiently to meet the needs of its users and stakeholders.

### Can this be done in six months?

Don't know. But we need to start having the conversations and see where it can lead.
Don't know. But we need to start having the conversations with stakeholders and see where it can lead.

### Getting documentation updated is hard. Who would do that work?

This may be the biggest blocker to making this goal successful. Part of this goal will be finding people who are interested in doing the work to author and review these updates or to find the budget to hire people to do this.

The safety-critical Rust community actively and passively benefits from the FLS, so it's worthwhile to solicit engagement with the Safety-Critical Rust Consortium.

### What happens if the FLS and Reference combine as one specification document?

That's actually a potential outcome of the `t-spec` work in the future. So this may not be totally theoretical. Hopefully the processes we come up with are not so document specific and they can withstand such a merger.
Loading