Cargo team meeting notes 2026-01-27

--- robots: noindex, nofollow tags: meetings --- # 2026-01-27 Attendees: Ed Page, Eric Huss, Arlo, Ross, Jacob (Eh2406), Dongpo, Josh Triplett, Weihang ## FCP Reminders - docs(report): enhance man pages for `cargo report *` -- https://github.com/rust-lang/cargo/pull/16430#issuecomment-3697735409 - build-std: always -- https://github.com/rust-lang/rfcs/pull/3874#issuecomment-3715844925 - build-std: explicit dependencies -- https://github.com/rust-lang/rfcs/pull/3875#issuecomment-3715845871 ## Team maintenance and support - Thoughts on the current health of the team? - Eric: The Foundation has been working on the maintainers fund. They want better understanding of the health of different teams. Josh is on the team working on that. - Josh: We want to figure out what the Project's looking for the funds to look like. We've got a team of people looking through what kind of funds do we want to do, how much, what should the application look like. Consistent year-over-year vs grants? How can we best help the project to have maintenance support where it needs that support to unblock the Project in places where there are bottlenecks. So: what do you know of that are things that are bottlenecking the project, things no one's working on because they're not paid etc. Find out all the corner cases. We hope to get something in this quarter to start the fund in the first half of the year. - Eric: Thanks Josh. What do people feel the health of the Cargo team is? - Weihang: Most of the PRs are reviewed by Ed and me, sometimes Eric. Ed and myself are hired by a company. If I got laid off, I might not have as much time as used to be. We did actually have layoffs - Ed: And in your case, everyone else got laid off so you had less time on this stuff. - Weihang: Cargo is a key component in Rust and the two of us are employed. If/when we get laid off, there's risk of Cargo would only have one maintainer. - Ed: Similar deal, there's constant threat of layoffs. - Josh: Everything Ed just said, I've also been experiencing that feeling: work wants different things and therefore there's less bandwidth. Cargo is not a top priority for the companies. At the moment we're healthy, but it's fragile and we could lose the bandwidth with a single decision by a single company. - Josh: We also have a massive heroic work done by Eric. It's deeply appreciated and also sounds like he may get massively overloaded. - Ed: Regarding ease of reviews, as I become more familiar it's gotten easier. But having better boundaries and limit the blast radius of faults would help. The plumbing project should hep us have a definite boundary between things. That would help Cargo be more maintainable. - Josh: That seems the state we're in in general. There are several things we could be doing that we don't have bandwidth for. It would be nice to have a threshold where everything gets triaged and things don't stay open because they're fixed quickly. - Ed: I filed two issues for clippy and they got fixed almost right away. - Eric: Ed & Weihang, do you feel stressed about the work you're doing? - Weihang: Not for Cargo. Yes from the job - Ed: Heads down working on Cargo, I'm not stressed. Doing cross-project stuff is a lot more stressful. - Eric: If either of you stops working, Cargo will go into a nearly feature-freeze state. Would we say the current state as "things are at the minimum"? - Ed: We're above minimum, but by losing someone we'll drop below minimum. We are moving features forward, but we're very vulnerable. - Josh: Regarding feature development pace, when you have people with more bandwidth, the work can be spread more easily. When there's little bandwidth, things stay open for longer. E.g. I should have finished the hints work some time ago, but I didn't have bandwidth. And there's a lot of things in flight like that. - Ed: It would be great to have someone focusing on things like summarizing all the unstable features and getting them unblocked. That would cut down on our unstable feature backlog. - Ed: We are blocked on cross-team stuff. E.g. we want to move forward with public/private dependencies. But we need a compiler person to help with it. For namespaces we've at least been given Microsoft interested. - Josh: If we take the whole Project view: we'd love more bandwidth and support more people. If there were incremental funding for 1 extra person, would we feel the best way for us would be go to Cargo? Or maybe on crates.io or other teams that would unblock us? - Ed: One potential thing would be be the cross-team enabler. Either grease the wheels or actually do the work to help. - Eric: That's a great point. One similar thing is rustfmt. And there it's actually pretty clear, but pub/priv dependencies are less clear. The compiler team is huge but we need to find someone motivated. - Ed: Referencing Mara's blog post: "Rust is not a business". We can't make someone do this, but we need a way to motivate them. - Tomas: Project goals were supposed to help with or solve. Why is that not happening? - Ed: Project goals are more concrete. This is more about team vision, and where you're going in the next couple of years. Ex, proc-macros vs decl-macros vs reflection. Each has tradeoffs. What direction should that go to move forward to solve problems. Not necessarily what I'm going to implement in the next 6 months, more about the direction. - Tomas: Niko is working on "north star" longer version roadmap to see what we want to achieve in the next few years. - Jacob: The Project goals were also helpful to clarify some of the issues. E.g. we need help from the compiler team for pub/priv. We knew it, the compiler team knew it. Now we have a project goal that makes it clear that it's stuck on having someone on the compiler team to move it forward - Ed: For namespaces, that's what helped to lead to a couple of people contacting me to move it forward. For pub/priv dependencies, Niko contacted me regarding this and see how we could support this. - Josh: Once we have a maintainer fund we could have someone to do this. - Josh: We have a Project manager across the Project. If we had the funding for more than one, we might more bandwidth for no t just coordinating, but also having a list of where each project is blocked - Tomas: The Council has approved budget for a second program manager who will start soon. - Eric: That's been great feedback, I appreciate it. - Josh: Are you going to one of the invited meetings with Lori as the team lead to report some of this? - Eric: Yes. Also, this is important information for me to know. Sometimes I'm uncertain about the health of the team. I'm never really clear of people's work status. And it changes all the time. This is true of all the other teams I'm involved with. And if we do find the money and start figuring out to distribute it, do we bring someone new or do we try to find one of us in the room here? - Josh: It is worth floating. Who on this team is paid to spend some portion of their team on Cargo. Or on Rust as long as other things don't take priority. - Jacob: And also, this changes rapidly. Your management chain may have different views person to person. - Eric: I feel uncomfortable that we have 88 pull requests open. I want to spend an hour with you to go through and close some of these. - Josh: If you'd like an hour, I can send you my meeting link. Especially if we have low-to-medium priorities that we can go through quickly. - Ed: It's important to send a clear message to contributors rather than things staying in limbo. And the PR count itself sends a message. I go over these from time to time. - Weihang: We're here because we want to contribute to an open source project. If we feel too responsible for our work here / backlog. That's a sign that maybe you should take rest and skip a week to recharge. That may make Cargo more healthier. - Jacob: And an aspect that something is bothering you, then it's important. - Eric: What Ed said: we're not communicating what the status is to the author. - Ed: I was working with another team and someone else posted a message to move the conversation forward. And then the team responded that "this is exactly the information I needed to unblock this!" and I didn't know that. I could have sent that message. ## Workspace discovery Try to wrap up the discussion from last week. - Confusion about broken `Cargo.toml` in $HOME: https://github.com/rust-lang/cargo/issues/6706 - Ed: It would be great for us to have some kind of stop searching, people are interested but not contributing to the design. I think we should put `needs-design` and move on. - Eric: The unstable feature may have meaning for the workspace but if you ignore it, the subpackages can build. Do we want to spend some time to support this use case? Or close the door saying nightly features are going to make your workspace nightly-only - Josh: In the case of: "I found a workspace, it's nightly, why can't I just support the nightly features?" -- we can just say that in this case you need to use nightly cargo - Josh: But you have a manifest, that manifest says nightly and you don't need nightly, we should have some way of saying "don't find that in the first place" - but I'd like to find what people usecases are. What are they trying to do that's making people's lives complicated. Have someone to explin their workflow in more detail. - Eric: Often this is because it's an accident. They may have `Cargo.toml` in their home directory or `/tmp`. - Eric: I've also seen people new to programming and made mistakes. They typed `cargo init` in their home directory. - Josh: That's something we could add extra protections for. E.g. `cargo init` could notice trying to initialize a cargo directory directly in `~`. And add a flag if you need it. - Ed: Why do we even need a flag? `init` is not a necessity, we can just show a clear error. - Ed: `init` isn't supported for programmatic use, so we can just change this. - Jacob: Some companies have telemetry, but we don't see people who are new to programming. I think Meta has good info on how Cargo is being used. - Arlo: Microsoft as well I think. They have their own rustup wrapper with telemetry built-in - Weihang: Same as Amazon - Jacob: Not to the same degree as Meta does. - Josh: We should record the "maybe we should make init home-aware" - Ed: I'll open an issue - We decided to just enhance the error message for this issue: https://github.com/rust-lang/cargo/issues/6706#issuecomment-3773784686 - Control of searching for `Cargo.toml`: https://github.com/rust-lang/cargo/issues/7871 - An option to control how far up cargo searches (or whether it searches at all?). - https://github.com/rust-lang/cargo/issues/7621 -- same issue for `config.toml` - Safe file discovery: https://github.com/rust-lang/rfcs/pull/3279 - Enforces ownership check, with an opt-out config to allow accessing files from another owner. Perhaps kick 7621 to "needs-design"? ## (backlog) Nightly features in a parent Cargo.toml causes build in unrelated sub-crate to fail when building with beta or stable cargo https://github.com/rust-lang/cargo/issues/6646 (continue from 2026-01-13) [notes](https://github.com/rust-lang/cargo-team/blob/main/meetings/sync-meeting/2026-01-13.md#backlog-nightly-features-in-a-parent-cargotoml-causes-build-in-unrelated-sub-crate-to-fail-when-building-with-beta-or-stable-cargo) Eric: I'm not sure how much we can do. The profile settings change how crates are built. Are we comfortable closing the issue given the complexities having to deal with this? Josh: I think we should close it. This is an unrelated subcrate. Maybe we can send them to the `package.workspace = false`? Ed: I don't think we have an issue for this. Josh: Can you please file an issue and close this in favor of that? Eric: What's different between `package.workspace = false` and having an empty workspace? Ed: We need to figure this out. One difference is if you do `cargo new` in the subdirectory, it won't add itself. I'm not sure that's enough benefit to be a separate field. Weihang: A random idea is to embed the cargo book in cargo's CLI, so things like AI agents can access that information. ed: Similar to `git help` has guide stuff in it, could generally be useful.