I, Max Gilmour, apply for upload rights for package-set rust.
Contact Information:
- Name:
Max Gilmour - Launchpad Page:
~maxgmr - Matrix username:
@maxgmr:ubuntu.com
I am applying because:
- The Rust packaging ecosystem has a large number of unique rules and quirks. This reduces the pool of potential sponsors.
- In particular, rustc itself is a difficult package to review and sponsor:
- The package isn’t downstream from Debian, meaning all changes for a new version must be reviewed by the Ubuntu sponsor instead of just syncing/merging.
- Each new upstream rustc version (which comes every six weeks) is uploaded as a new package, meaning that a rich git-ubuntu commit history is unavailable.
- A huge portion of the changes between upstream versions is taken up by updated vendored dependencies.
- As of May 2026, the Rust toolchain team consists of six people, none of whom have any upload rights whatsoever. In order to do our work efficiently, we need someone with Rust-specific knowledge to know what to look for when sponsoring uploads.
- In any given work day, there currently exists a gap in time in which no toolchain team members with upload rights are active. As the westernmost member of the toolchain team, getting upload rights means I would be able to fill that gap, allowing toolchain team members to have their work reviewed/sponsored at any point of their work day.
- Amongst the Rust toolchain team, I have the most experience working with the various Rust toolchain packages. In particular, I have been responsible for all Rust toolchain uploads from Rust 1.85 (July 2025) onwards.
- As the uploader of each new Rust toolchain, I know the changes from one toolchain version to another best, so I’d be best equipped to diagnose and fix failures during Rust toolchain transitions. For instance, I was easily able to diagnose a mozjs140 FTBFS as being caused by a new platform because I was the one who added the new platform in the first place!
Who I am
I am a Rust Toolchain Engineer as a part of the Canonical Foundations team. I have worked at Canonical since March 2025. Currently, my primary responsibilities include keeping the Rust toolchain in the Ubuntu archive in sync with upstream, improving the Ubuntu Rust packaging experience, and improving the Rust developer experience on Ubuntu.
My Ubuntu story
My history as a software engineer and my love of Ubuntu are inextricable. My first exposure to both programming and Ubuntu was in high school. We had an Ubuntu machine in the computer lab which I used to write code for my school’s FIRST Robotics team.
I used various Linux distros throughout university, and I continue to do so to this day for my personal machines. I use Ubuntu to power my homelab, which I use for backups, data storage, and a media server.
Since March 2025 I have had the honour of working at Canonical to make Ubuntu the best place to develop Rust applications.
Examples of my work / Things I’m proud of
Uploaded packages (LP)
Ubuntu Sponsorship Miner
As shown above, my most notable uploads are the new versions of rustc as new Rust versions are released.
Since most of my work is on the Rust toolchain, I don’t need to submit fixes to Debian very often. However, when working on Ubuntu packages downstream from Debian (for example, during my +1 Maintenance shadowing shift), I always make sure to fix the bug in Debian unless an Ubuntu delta is strictly necessary:
As the Rust toolchain maintainer, I do my best to stay aware of which packages will be affected by my toolchain uploads and ensure they’re maintained properly:
- For instance, my addition of the RISC-V RVA23 target caused a mozjs140 FTBFS because the package hardcodes its targets in its build script. To avoid an unnecessary Ubuntu delta, I submitted the fix through Salsa.
- I will typically test-rebuild a selection of important Rust packages in a PPA before requesting sponsorship for a new default Rust upload. This has caught several bugs preemptively: for example, I caught a Lace FTBFS and merged my fixes in before the FTBFS even happened in the actual archive.
I am also determined to handle the responsibility of keeping up with upstream news and updates. For instance, I reported and triaged CVE-2026-33056 via LP: #2145764, mobilizing the whole Rust team to address the CVE as quickly as possible.
I’m the most experienced member of the Canonical Rust team from a packaging point of view, so I’ve made efforts to assist my teammates and teach them how to maintain the toolchain. Most notably, I took the initiative and wrote documentation on updating and backporting Rust toolchains. They are used as our team’s source of truth, and I consistently keep this documentation up to date.
Within my team, I have served as the go-to person to ask for help and reviews when it comes to Rust packaging questions, so I’m eager to make it official!
Areas of work
Right now, my work is mostly dedicated to keeping the Rust toolchain in sync with upstream and ensuring that packages affected by my Rust toolchain upgrades work properly. I’m also responsible for integrating many new features into newer Rust toolchain releases, such as the move to the RISC-V RVA23 profile in rustc-1.92 or the packaging of rust-miri in rustc-1.93.
Things I could do better
Looking back at my past uploads, I believe that I should take more time to understand the reasoning behind functioning solutions. More precisely, if a particular solution works, then I sometimes don’t spend enough time to learn why that particular solution works.
For an example of this, I originally had the meaning of the i386 allowlist reversed: I assumed that the i386 allowlist was a list of packages which are allowed to fail on i386, not packages which build for i386. Therefore, I never test-built the Rust toolchain for i386 in my PPAs. My mistake was this: I saw that the actual Rust toolchain uploads in the archive did indeed have i386 uploads, but I never questioned why this was the case because the uploads were working fine… Until, of course, one day the uploads didn’t work, and there was an i386-specific FTBFS in one of my toolchain uploads which I would have caught if I was test-building i386 in my PPAs.
In order to combat this tendency of mine in the future, I must remember to exemplify the spirit of cooperation promoted by Ubuntu and take the initiative in asking others about things I’m not sure about, even if those things aren’t directly blocking me at the moment. In the previous example, I should have asked someone why there were i386 rustc builds when I expected there to be none, even though the i386 builds weren’t failing.
Plans for the future
General
My Rust toolchain specialization, and by extension my Rust packageset application are significantly motivated by necessity. I want my team to be able to do their jobs as easily and efficiently as possible. This means that my non-toolchain uploads are pretty few and far between. In the future, I’d like to change that. I want to become a more well-rounded contributor to Ubuntu and improve my skills in other parts of the distro as well. While the nature of my career has so far pushed me towards one specific region of Ubuntu, I hope to devote time to a more diverse set of skills and eventually gain the wide range of experience needed for MOTU and beyond.
What I like least in Ubuntu
I think there’s room for improvement in terms of how we handle package migrations. For instance, failing autopkgtest infrastructure is a part of life, but it would be nice for the update excuses page to provide more info on the nature of specific failures. For instance, autopkgtest.ubuntu.com is able to distinguish between “tmpfail” and “fail” – why not the update excuses page?
While there are indeed benefits to static linking in Rust (and, in the case of Rust packages in main, vendoring), I must think about how to mitigate the many downsides. For instance, fixing a vulnerable crate involves tracking down all the packages which statically link in that crate’s code, then additionally tracking down and fixing any packages which vendor their dependencies. This is a necessary process, but it’s my job to figure out ways to make this process as reliable and easy as possible.
Endorsements and Comments
For those of you who wish to endorse my application, please use the template below:
## Sponsoring feedback
* Please fill us in on your shared experience.
* How many packages did you sponsor? A list of sponsored packages can generated [via UDD here](https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi)
* How would you judge the quality?
* How would you describe the improvements?
* Do you trust the applicant?
## Specific experiences of working together
*Please add good examples of your work together, but also cases that could have handled better.*
## Areas of improvement and next steps
What is the journey you see ahead of the applicant, the next steps they should take, the next things they likely have to learn and the next mountains to climb?
Thank you!
