Announcing the Infrastructure, Cargo, and Dev Tools teams; disbanding the Tools team

announcements
1

Hello friendly Rustaceans! I have a pile of news to share with you today, all connected to further expanding the Rust subteams. You can see the full roster here.

The core team has long recognized that the tools subteam covers a very broad set of topics, which has made it difficult for the team to be effective. At the same time, we're pushing hard this year to further expand Rust leadership and promote more members of our amazing community into leadership roles.

After a couple months of legwork, today we're announcing that the tools team is being disbanded and broken into three new, more focused subteams:

The Dev Tools Team, led by @nrc. In his words:

The dev tools team is responsible for tools for reading, writing, and debugging Rust programs. We want the tools ecosytem to be so awesome that it's a reason for developers to choose Rust.

We're going to be working on the RLS and IDEs, Rustdoc, Bindgen, and a bunch of other tools. This year we want to deliver IDE support, make contributing to tools easier, make some big improvements to Rustdoc, and make Clippy available on the stable Rust channel, as well as exploring some new and exciting tool ideas.

The Dev Tools team involves two groups of people: members of the team itself, and a set of "tool peers". The direct team members are responsible for cross-cutting concerns that apply to multiple Rust tools (e.g., the RLS as a foundation for tools), and for setting the overall direction of Rust's official tooling story. The tool peers oversee specific tools (like bindgen, Clippy, or rustdoc), and coordinate with the dev tools team as needed. @nrc will be writing about the process here in greater detail soon.

The initial roster is:

IRC room: #rust-dev-tools Github label: T-dev-tools

The Cargo Team, led in interim by @aturon.

This team covers the design and implementation of Cargo and crates.io. Our goals for the foreseeable future include:

  • Broadening Cargo/crates.io maintenance to include more of the community (getting on top of the issue tracker; making the implementation more approachable; mentoring projects).
  • Articulating key aspects of Cargo's vision and design philosophy, in a way that can inform ongoing design discussions.
  • Developing our story for build system integration.
  • Landing the public/private dependency story.
  • Adding support for multiple registries.
  • and much more; as the team continues to gel, we'll start putting together a more detailed roadmap.

To start, @aturon will be leading this team, in a largely facilitating role. Over time, one of the other members will ultimately step into long-term team leadership.

The initial roster is:

IRC room: #cargo Github label: T-cargo

The Infrastructure Team, led in interim by @aturon.

This team was previously launched in an unofficial way, but is now being fully formalized as a subteam. Its mission is to care for all of the infrastructure used for running the Rust project, spanning CI, releases, metrics, bots, and more.

Some of our immediate goals are:

  • Geting the PR queue to a steady place. You may have noticed the new S- tags tracking PR status. Full details of our PR triage procedure are here. We're also tracking and hunting down spurious build failures.
  • Maturing Cargobomb (the successor to Crater, which is able to run test suites) and opening up its maintenance.
  • Stabilizing and improving http://perf.rust-lang.org/, our compiler performance tracker.
  • Completing a dashboard that can become a daily part of Rust contributor's workflow.
  • Increasing the number of people who can respond to outages for critical services (crates.io and rustup).
  • Introducing more visible infrastructure monitoring.
  • In the longer term, improving the security for and documentation of all of our infrastructure.

As with the Cargo subteam, @aturon is initially facilitating the team as lead (but leaving all the real work to the awesome volunteers). Once we've fully hit our stride, I'll look to hand over the reigns.

Initial roster: @brson, @alexcrichton, @frewsxcv, @shepmaster, @aidanhs, @TimNN, @carols10cents, @Mark_Simulacrum , @erickt, @aturon

IRC room: #rust-infra Github label: T-infra

Finally, there's one element of the old tools team that will ultimately need to be covered elsewhere: "platform" issues around things like linkers, the deep guts of std, and other highly platform-specific work. For the moment, this will be tackled informally by @alexcrichton, @brson, and @vadimcn, but will likely become a team of its own right in the future.

Whew, that's it! What an exciting time in Rust land. Please let me know if you have comments or questions.

30 Likes
2

Finally! \o/

Thanks for your work on this!

3

I feel like this is a great idea. While I agree that splitting the tools team will allow for more focused conversations and goals, I think that this split may make contributing even easier. Joining a conversation that focused on a smaller scope is significantly easier. Very excited by this.

:+1:

2 Likes
4

Yes, absolutely! And it should make it easier to mentor and grow new members for these subareas over time as well.

1 Like
5

I’m a little disappointed to not see rustfmt mentioned at all here, since it’s by far the Rust tool that I get frustrated with the most. Is there a reason that it isn’t being given the same status as racer and clippy?

1 Like
6

Rustfmt is definitely on the radar for the dev-tools team and we’ll be working on making it more available in the near future (plus of course, ongoing improvements). It’s just that there are a lot of tools, and it would have taken too much space to mention them all! (There isn’t a Rustfmt peer, because I am the primary maintainer and I’m already part of the team).

4 Likes
7

Awesome, thanks for the explanation! I was a little worried after not seeing it mentioned, so I’m glad that it will continue to be developed.

8

Excited to see the Tools team grow! Especially with RLS getting more attention :wink: Does that mean that #rust-tools is now “deprecated” and people should now move to appropriate, listed channels here?

9

Less than a year later, I’m blown away by how amazing my experience is using rustfmt. I barely ever get errors saying that rustfmt isn’t able to trim a line short enough, and the ability to specify a config file (which might have been available at the time of my last comment, although I at least wasn’t aware of it) works beautifully. I just wanted to come back here to say thanks for all the great work that’s been done since this announcement!

4 Likes
10

What about bug / issue tracker for union tool project?

For example if I want to use bindgen + rustfmt + clippy in the same project, I need stable + beta + nightly at the same time, because of rustfmt is part of beta component of rustup, bindgen at now depend on .so library from stable (if you build it with stable as I did):

error while loading shared libraries: libproc_macro-6572f0cb64bf7b5a.so: cannot open shared object file: No such file or directory

and clippy obviously works only with nightly.

This is very frustrating for novice. And not clear to which repo report such kind of problem?

Our how about cargo hell problem, if you work with large project, then obviously you need at least tool that show dependencies with the same name, but different version. And it is not clear about which project I need reports this feature request: cargo-tree, cargo by itself, or some other project?

11

I believe this is cargo tree -d.

12

Looks promising, but cargo tree doesn't work with workspace :frowning: Without these this cargo tree -d functionality is useless, because of more simple is run cargo tree for each crate in workspace and merge results to find duplicates.

13

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.