# Lang-team / RFL Sync (2024-02-12)

## Agenda

* Compiler compatibility, preview
* Proposal for ongoing interaction
* Future deep dive discussions

## Compiler compatibility, preview

RFL currently depends on a [set of nightly features](https://github.com/Rust-for-Linux/linux/issues/2). In principle these features can change in incompatible ways from nightly release to nightly release. Long term, the goal should be that RFL is able to build purely on stable. But in the meantime, RFL project organizers would like to have some amount of stability promises -- e.g., knowing that the RFL codebase will continue to build with the same semantics over some set of releases (note that this does not imply that the unstable features in use can't change, only that they must continue to support the patterns used in RFL).

Questions to be resolved:

* Is this an accurate summary of RFL's desire
* How long should such a stability guarantee last to be useful (currently, it lasts 1.5 months, which is too short; is 3 months enough? 6 months? 12 months?). What's the right balance?
* How can we test it to be sure that we are keeping that guarantee?
* How do we coordinate when changes do need to be coordinate?

In previous meetings, RFL organizers mentioned [preview features](https://smallcultfollowing.com/babysteps/blog/2023/09/18/stability-without-stressing-the-out/) as one possible solution. This could indeed be great but it would require building consensus around a design for preview features. Before doing that, it would be good to know exactly what RFL's needs are and whether we can do something in the shorter term to meet them.

Strawperson proposal:

* Some kind of crater setup that tests each Rust PR against RFL codebase to prevent regressions.
* RFL builds against latest stable release with RUST_BOOTSTRAP=1.
* When a regression is planned, ping RFL folks to coordinate the release in which it will go out.
* When RFL users wish to take a new feature gate, RFL users ping Rust to check if it is considered "ok".

## Ongoing interaction

How should the RFL and Rust groups interact on an ongoing basis? Observations:

* In-depth discussions about specific features work best with small groups
* Participants in both RFL and Rust are busy folks and coordiante calendars is challenging

Information that the Rust project wants from RFL:

* What new features are you thinking of using but aren't using yet
* What are pain points that you cannot find an appropriate feature to solve

Information that RFL wants from Rust:

* Updates from focused groups on progress so far
* this to be done by having the RfL members in the subgroup sync with other RfL members and Rust members sync with Rust members

Strawperson proposal:

* Dedicated groups pursing particular features (enumerated below, but we can start new efforts easily enough)
* Within those groups, Rust folk report back to broader Rust teams
* RFL folk report back to broader RFL community
* Create a `rust-for-linux` Zulip stream and GH issue tag
* Each new issue with `rust-for-linux` tag
* Regular RFL-specific "office hours" at a particular time
* Rust folk make themselves avaiable at this time
* If RFL person has a topic they wish to discuss, they open an issue on a `rust-lang/rust-for-linux` github repo
* Via automation this opens a topic in the `#rust-for-linux` stream to permit asynchronous discussion
* When office hours occur, we will review open tickets, closing them as they get resolved
* Larger syncs to be coordinated on an "as-needed" basis, conferences are particularly useful
* Starting with Rust Nation, perhaps RustConf in the US?

## Focused discussions

Proposed groups for focused discussion. Each of these groups should have 2-4 people, including some from Rust and some from RFL, and have a specific goal. They'll discuss on their own time, establish a goal and timeline, and then try to meet it.

### Arc

* People (RFL): Alice Ryhl, XXX
* People (Rust): joshtriplett, nikomatsakis (?)

Proposed goal: enable Arc-like types that support participation in Linux kernel linked list as well as support for unsized types

### Feature review and bucketing

* People (RFL):
* People (Rust): joshtriplett ?

Proposed goal: stabilize a subset of the features used by RFL

Path forward:

* bucket unstable features used by RFL into (small, large, research-project) buckets
* drive stabilization of the "small" features

Initial rough assessment (joshtriplett): https://hackmd.io/r556bZKeSdu0cWwurlHjpw?both