Welcome to the second Rust PM update!
Things were a bit busy in personal life. We had to temporarily move to a smaller apartment which was quite time-consuming and energy-draining. And after that, I took a week off and we spent it in the mountains.
So things were slower in July. What dominated was the Project Goals work.
As we entered the second half of the year, it was time to wrap up the current Project Goals and get the new ones going. In the spirit of helping people focus on other things, I took this over.
First, I've sent a couple requests for goal updates. This lead me to noticing and filing an issue with triagebot. More details in the ping-goals retry section.
After people provided their final messages, I've published the final 2025H1 Project Goals update:
https://blog.rust-lang.org/2025/08/05/july-project-goals-update/
With that done, I've closed most of the tracking issues. Some goals are being renewed for the H2 period so we're keeping those open.
With all of that out of the way, Niko published the call for 2025 H2 goal proposals.
Based on the feedback we've received, we've made some changes in this period:
Once all the champions are selected, we'll meet with the team leads, go over the goals and figure out which ones we want to accept.
Similarly, we'll take their input regarding flagship goals.
As the goals were being proposed, Niko, Rémy, and I looked at the PRs, fixed any CI issues, and merged them.
For each team, I've opened a "call for champions" Zulip thread listing the goals that requested their support. Here's an example for the Lang team.
As with any new process, people had questions. I was there to help clarify what we're asking for, the overall plan, and next steps. When there were specific questions for a goal, I made sure to connect the right people.
In 2021, the Rust Foundation created the Security Initiative. Their focus is on improving the security of the Rust ecosystem by building security tools, conducting audits, creating threat models, and developing security expertise.
At the beginning of the year, they opened a goal to provide crates.io verification and mirroring:
Rustaceans need to be able to download crates and know that they're getting the crate files that were published to crates.io without modification. Rustaceans everywhere should be able to use local mirrors of crates.io, such as geographically distributed mirrors or mirrors within infrastructure (e.g. CI) that they're using.
There's a good analog to this with Linux packaging (e.g. apt or dnf): when you install a package (or upgrade your system), your computer will rarely talk directly to the main package registry. It's far more likely that it will reach a mirror hosted by a university, scientific institution, your ISP, or, in the case of CI, its provider. This lets people install their packages more quickly while saving on the upstream bandwidth and other costs.
You can do all this today with a crucial difference: how do you know that the host (or someone in-between) didn't tamper with the code? How do you know you're getting the exact same bits as if you were to reach crates.io directly?
That's broadly what the goal is about, and it involved investigations of the signing algorithms, key rotations, CI integration, releases, logging, and much more. And all of this must meet the scale and performance requirements of crates.io.
Walter Pearce and Josh Triplett did most of the work (investigation, experimentation, looking into what other package managers are doing) and talked to Cargo, Infra, Release, Bootstrap, and crates.io representatives.
Last week, Walter posted a final update on the goal's tracking issue.
The goal owners along with the team representatives agreed on the following to build an experimental MVP implementation:
They also reached a consensus with the Infrastructure team for deployment planning. The plan is for the MVP to be ready by the end of August, and they'll use it to test various optimizations to make sure it works for our tooling (rustup, releases, crates.io, etc.).
This will answer some of the open questions (which specific optimizations will fit our needs, how to implement the Merkle tree to reduce round trips, and details on hosting infrastructure) and provide enough information to write the RFC and make this fully supported and available.
These discussions and decisions happened in meetings, and there was little public communication to the rest of the Project. One of my goals is to start publishing more frequent and detailed updates on this and similar initiatives.
I've joined the signing meetings to be more aware of what's happening within this initiative.
Rust for Linux is an ongoing effort (started in 2020) to add support for Rust to the Linux kernel. The project allows people to write kernel code, such as drivers and other modules, in a memory safe language, with hopefully fewer bugs and nicer tooling. In addition, one of its goals is to allow more people get involved overall in developing the kernel thanks to the use of a modern language.
The project currently has to rely on unstable Rust. This makes it less appealing for companies and individuals as unstable features can by definition change or even be removed. We want there to be minimal (ideally zero) churn on Rust code that's been accepted to the kernel.
There's been an ongoing collaboration with the Rust Project to get the language, compiler, and tooling to a point where it can be completely compiled on stable Rust.
Rust for Linux was a flagship goal the second half of 2024 as well as the first half of 2025.
This effort requires close collaboration with the Lang and Compiler teams, among others, and contact points on both sides to bridge the gap between the two projects. Until now, that was done by Niko Matsakis, TC, et al. on the Rust side and Miguel Ojeda et al. on the Rust for Linux side.
One of the hopes of the PM role was to be able to step in and improve the communication between efforts like these and free up the Project members' time.
I am now running the meetings, preparing the agenda, making sure the tracking issues are up-to-date, and bringing any requests or concerns to the relevant Project teams or people.
Miguel Ojeda will continue to be the point of contact on the Linux side.
I helped Miguel propose two 2025 H2 goals (compiler and language features for getting Rust for Linux into stable Rust) and should they be accepted I will be the Point of contact for them.
This lets Niko disengage from the program completely and focus on the many other things he's doing across the Project.
ping-goals retry issueThe request for updates is done by the ping-goals command of @triagebot. This returned an error ("Failed to await at this time: connection closed before message completed"), but did actually ping everyone. Multiple times, in fact.
As you can see in the thread, this wasn't a new behavior either. Precisely the sort of paper cut I care about improving for everyone:
https://github.com/rust-lang/triagebot/issues/2108
Urgau looked into it and found out this is because rustbot was sending the pings one-by-one and taking some time to finish.
Zulip interpreted this as a timeout and retried the requests a few times.
Thank you Urgau!
The Leadership Council is a team charged with the success of the Project as a whole. They're composed of members of the top-level Rust teams.
The Council meets every two weeks and after each meeting they publish minutes to the leadership-council repository.
This makes them accountable to the teams they represent and transparent to the Project and the community as a whole. It also helps others find if they're missing something important so it can be brought to their attention.
As with every other meeting, when an active participant has to take minutes, this results in diminishing that person's attention to the topic as well as the quality of the notes (most people can't speak or fully consider what other people said and write at the same time).
And similarly, going through the minutes, making them legible and publishing them takes additional effort and attention. When these things pile up, they can even lead to burning out valuable contributors.
Having taken over the minutes for the Leadership Council meetings in June, I've now closed the loop by taking over the clean-up and publishing as well.
I've collected a few numbers to show some of the regular work that's happening.
Total words of meeting minutes written: 92.6k (June + July). That's more than the novel I'm currently reading!
Meetings attended: 24
Total words written: 51.5k
Average (mean) word count per team meeting:
In contrast, this is the week when I was away:
Meetings attended: 39
Total words written: 41.1k
Average word count:
I wasn't here in May so these can serve as a comparison.
Meetings attended: 0
Average word count:
More words doesn't necessarily mean better and there are other aspects that affect this: number of people in the meeting, how much discussion a topic needs, etc. And this is not a target I or anyone else is holding me to.
But it is kind of interesting to see.
If you have an idea for any more useful things to track, please let me know!
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。