Project state‐of‐union priorities needs

Project state

Rustup is broadly feature complete : most users get what they need most of the time. There is a stream of small updates needed as the ecosystem changes (e.g. the recent loongarch64 enablement). There are some tradeoffs that need reviewing and re-evaluation such as not falling back to copy during installs. And there are some thorny problems that provide a continual tax on everyone such as the lack of concurrency safety.

Priorities

Right now we manage to deliver 0 consistently, 1 usually, and 2 is spotty, the rest happen from time to time very inconsistently.

0. Unplanned work:

• Deal with CVEs in concert with the Rust security team
• Deal with regressions

1. Facilitating non-team-member contributions:

• Discussing designs in the bugtracker / on Discord
• Merging ready to merge PRs
• Cutting releases when enough features are present

2. Keep on top of bug triage. Broadly these break down:

• Many new bugs are not strictly rustup defects, but rustup acts as the messenger and gets the blame.
• Quite some bugs are new reports of the thorny problems that are well known.
• And then there are some cases where we have a defect and should fix it (e.g. wrong message in an error, or excessive memory use in some situation).
• And finally bugs that really are proposals for doing something differently, e.g. UX changes where there might be no right answer

3. Keep the code up to date:

• Fix (usual case) or disable (where the fix makes rustup code worse) new clippy lints
• Update dependencies (largely automated via Renovate these days)

4. Invest in making things better

• We have several long term refactoring efforts in progress:
  • Moving tests close to the code under test
  • Improving code clarity/structure/modularity
  • Migrating to async
• Keeping / improving rustup performance
• Working on some of the thorny problems
• Making rustup concurrent-install safe

5. Speculative would-be-nice long term things

• Revamping the download/install mechanism to be radically faster and more bandwidth friendly (e.g. use a content addressed store locally rather than downloading archives)
• introduce a programmatic interface to rustup (e.g. a rustupd or a rustup serve that speaks some protocol over stdin/stdout)

Project needs

Rustup needs contributions in all of the priorities above.

Rustup's domain is complicated, many changes cross team boundaries, and it - like most projects close to Rust itself - is used by millions of people day, making change compatibility quite important. Unlike the rest of the Rust core, Rustup has no boundary to make incompatible changes around, as one version of rustup installs all versions of Rust.

Sustained low-key contributions are probably more valuable than a large amount of contribution for a short time: getting familiar with the domain, with the history, with users needs, all takes time but is necessary for effective contribution.