Application - SRU Developer - Wesley Hershberger

Community Ubuntu Developer Membership
1

Application - SRU Developer - Wesley Hershberger

I, Wesley Hershberger, apply for Ubuntu SRU Developer.

Contact:

  • Name: Wesley Hershberger
  • Launchpad Page: ~whershberger
  • Matrix: @whershberger:ubuntu.com

I am applying because:

  • I’d like to eliminate delays in getting my work sponsored
  • I’d like to reduce the burden on my sponsors
  • I’d like to be able to sponsor the work of others (those in my Canonical team and more broadly)

Who I am

Hi friends,

My name is Wesley Hershberger; I currently work for Canonical in the Support Engineering department. In my tenure I’ve worked hands-on with our customers as a Support Engineer, as a developer on loan to the LXD team, and now as a Sustaining Engineer bridging the gap between support and the rest of the engineering organization. Currently I work as a Dedicated Services Engineer with one of Canonical’s cloud partners.

I grew up in Illinois but am currently based in Wisconsin; when I’m not tinkering on my homelab I enjoy making music and riding my bike on the excellent local trail system. I especially enjoy short bikepacking trips to nearby county and state parks.

My Ubuntu story

My dad introduced me to Linux while I was still in middle school; my first laptop was quickly converted to Ubuntu Trusty (14.04), and my next one ran Wily (15.10) to work around a kernel bug that hadn’t been fixed in Trusty. I tinkered with a bunch of distributions in high school and landed on Manjaro for a while; at this time I was also learning programming (D first, a bit of Python). I got hooked on contributing to RedoxOS as a way to learn Rust, and owe a lot to the maintainers for coaching me through my early Rust days.

My work on Redox got me in the door at a large insurance company where I was an intern with their Linux Engineering team during the summers of 2019 and 2020; during those few months I implemented a self-service Debian repository API for use on their Ubuntu infrastructure.

In college I chased deeper knowledge in programming languages (assembly all the way to Haskell), compilers, dipping a toe in Computer Science pedagogy and finishing it all off with a notable but ill-fated foray into distributed systems. By this time I had wandered back into the Debian/Ubuntu fold, daily driving PopOS.

I joined Canonical in 2023 as a Cloud Support Engineer, where I was quickly drawn to cases involving Ubuntu packaging: customers sorting out dependency issues, wanting clarification on CVE mitigations or trying to understand the status of bugfixes going through the SRU process.

I spent most of 2024 on a part-time secondment with the LXD team, getting to experience the role of an upstream developer. I landed a few features and fixed a small mountain of bugs.

Since early 2025 I have been working with Canonical’s Sustaining Engineering team to fix bugs in any software that falls under our scope of support. Our largest volume of bugs comes from OpenStack but we work on packages throughout the archive. Most recently my focus has been on QEMU and libvirt.

Examples of my work / Things I’m proud of

  • Uploaded packages: ~whershberger/+uploaded-packages, UDD
  • Chronological upload highlights (not the full list):
    • opensc 0.22.0-1ubuntu2.1 - My first SRU/upload. All the style issues here sent me on a search for a better way to manage patches
    • netplan.io 1.1.2-2ubuntu1.1 - I found a better way to manage patches! Lukas got me hooked on gbp pq, which I’ve used to prepare all my uploads since.
    • horizon 4:24.0.0-0ubuntu1.3 - First OpenStack SRU. This is not my best work - I never was able to identify the root cause.
    • tcpdump 4.99.5-2ubuntu1 - This upload was not associated with any work for Canonical, I just wanted to better understand the merge process for when I will (inevitably) need to get upstream changes into ubuntu/devel
    • dconf 0.40.0-4ubuntu0.1 - A long saga of upstream and downstream engagement to finally land this fix for our customers using DISA-STIG. This was a good learning experience both technically (version number corner case, different changes landing in stable than in devel) and socially (work with a dedicated Debian/Ubuntu maintainer and getting buy-in from sponsors)
    • devscripts 2.22.1ubuntu1.1 - Quick response to rmadison down as a result of PS5 scream test; build in -proposed failed due to lack of dilligence on my part. Began writing a tool to auto-build SRU submissions in PPAs.
    • qemu 1:10.1.0+ds-5ubuntu2.5 - I fixed an upstream race condition in QEMU and eventually submitted an SRU for Ubuntu. My uploads were superceded by a security fix, requiring a rebase.
    • rclone 1.60.1+dfsg-4ubuntu3.1 - Medium CVEs sponsored to the security pocket by the security team
  • Ubuntu Collaboration
    • LP: #2119987 Upstream OpenStack bugfix & SRU template. I had to hand this off to a colleague due to shifting responsibilities & challenges for verifying OpenStack SRUs.
    • LP: #2126923 While there isn’t much public-facing evidence, I helped Leah on her first SRU submission.
    • LP: #2155048 I did the first rounds of review on Alex’s first SRU.
  • Ubuntu Misc:
  • Debian:
    • ripgrep 15.1.0 (see MR) - I use ripgrep every day and also wanted to learn about Rust packaging in Debian (knowledge that has been useful in more recent SRUs).
    • crc-fast - First new package in Debian
    • autopkgtest - Fixing autopkgtest’s LXD virt provider for LXD remotes & adding support for LXD projects
    • gbp - I’ve been working on preventing gbp pq export from touching patches other than the ones that the user is interested in. While that work hasn’t landed (I’m still unhappy with the semantics I’ve chosen), I’ve worked on the CI, added Python type annotations and fixed a bug.
  • An honorable mention to my work in LXD, where I fixed many bugs, landed many improvements, implemented a feature in the storage subsystem and overhauled the procedure for Raft cluster recovery in case of permanent quorum loss.

Things I could do better

  • Always always always do PPA builds for every series before submitting an upload for sponsorship. I know that our SE sponsors typically do this anyway so I’ve let it slip in the past. Every miss like LP: #2142712 is an opportunity for better tooling.

Plans for the future

General

I will add myself to the Sustaining Engineering sponsorship rotation and begin to sponsor the work of my colleauges for the stable releases. I plan to be very conservative in what I pick up to sponsor for the first while, so as to maintain a high quality of uploads landing in unapproved.

What I like least about Ubuntu

The convoluted maze of build tools and the lack of high-quality, up-to-date, (non-conflicting,) documentation for building and testing packages in Ubuntu. This makes it very challenging for potential contributors (including new colleauges) to contribute and makes one-off contributions extremely rare.

Personally, I finally landed on autopkgtest for iterating & gbp + custom sbuild wrapper to build packages using LXD. But it has taken a year of accumulated knowledge of the ecosystem to arrive at a solution that just “does the right thing” in one command:

  • Revision control using git
  • Run directly on my workstation without requiring build-deps
  • Pack .dsc with dpkg-source
  • Produces a ..._source.changes that’s suitable for upload to PPA/archive
  • Test build the package in a container with optional lintian & autopkgtest
4 Likes
2

Matthew Ruffell - SRU Developer - Endorsement for Wesley Hershberger

Sponsoring feedback

I have reviewed and sponsored the following packages for Wesley:

I have had the opportunity to sponsor more packages for Wesley, but I have told
him each time to find a different sponsor to broaden the base of potential
endorsers when it comes to applying for this very set of upload rights. Wesley
has indeed met my challenge, and has met the expectations of everyone who has
uploaded work for him, making me very pleased with the quality of his work, and
his confidence to reach out to others for help with uploading.

Wesley very quickly took on my initial feedback for his very first upload, and
all uploads since then have been very high quality. Wesley takes the time to
write high quality SRU templates, with good impact statements, and excellent
testcases, and thinks about the risk of making each change.

Wesley is a regular attendee of my AMER/APAC SEG Sponsorship Office hours, where
we go through the list of bugs needing sponsorship, and we go through the SRU
templates and the patches, and Wesley always shares his thoughts about particular
bugs, and his feelings on them. Sometimes Wesley even catches minor details like
dep3 tags before I do.

Wesley has been known to help SEG new joiners come up to speed with writing
quality SRU templates and helping with the debian packaging journey, and is
even starting to help review bugs and approve merge requests even before the
Sponsorship Office Hours, so minor problems can be addressed quickly, and to
ensure things go smoothly when it comes for me to review.

Specific experiences of working together

Wesley has always been at the forefront of packaging and sponsoring improvements,
and recently has always been pushing for the use of git-ubuntu and Launchpad
Merge Requests. Myself, well, I had been leaning into the old ways a little too
much, with debdiffs and manual review, but Wesley has encouraged me to work more
with git-ubuntu, and I now am starting to prefer the git workflow more than
plain debdiffs.

The rust-time upload in LP2136226 - rust-time
was my first git-ubuntu style upload with the Vcs-Git / Vcs-Git-Ref / Vcs-Git-Commit
tags, due to a challenge from Wesley to start using the git based process.

At the Madid 2026 engineering sprint, Wesley and I sat down together during the
AI hackathon and made a number of improvements to SRU Lint
by peer programming with the LLM, and we made immense progress over that day
and landed Ubuntu Cloud Archive support to the linting tool.

Areas of improvement and next steps

After LP2142712 - devscripts failed to
build in -proposed, Wesley and Dariusz learned a solid lesson of why we always
build in two ppas during sponsorship, one with -updates and one with -proposed,
something which I try to instill in everyone who attends my Sponsorship Office
Hours, to make sure things build correctly when they get accepted into the
archive. Wesley now always builds with this approach, although I hear he does
it a lot locally these days with sbuild.

For Wesley, I think he will jump at the opportunity to help review and sponsor
uploads for members of SEG, and also the wider company. I am looking forward to
when he is available to help reduce the sponsoring burden for SEG uploads from
myself and Dariusz.

I see Wesley potentially going through the community wide sponsoring reports
and helping community members, and potentially working a patch pilot shift in
the future.

Long term, I think Wesley will likely head towards coredev, and I know he wishes
to work toward becoming a debian developer too.

Matthew Ruffell 2026-07-07

1 Like
3

Stefan Hammer - Engineering Manager, Canonical Public Cloud - Endorsement for Wesley Hershberger

Specific experiences of working together

As Engineering Manager for the Canonical Public Cloud (CPC) team, I lead cloud image development for some of our partners. Wesley is one of two dedicated engineers from Support Engineering (SEG) who works with my team to support critical packages outside the standard SRU process. These packages are private and shared only with key cloud partners, so I cannot provide specific details here. However, I fully endorse Wesley for stable release upload rights based on his demonstrated engineering rigor, collaborative nature, and focus.

Although our joint release process bypasses the formal SRU pipeline by delivering directly to cloud partners via PPAs, Wesley voluntarily applies SRU template principles to our updates. He evaluates and documents change impacts, defines and executes test plans, and proactively communicates potential regressions. Much of this testing relies on cloud partner infrastructure and access to their labs. Wesley is tightly integrated with these partners, coordinating verification in restricted environments to ensure risks are effectively mitigated.

Wesley provides excellent patch reviews and deep dives into technical details to minimize downstream maintenance debt. He has a proven ability to troubleshoot complex field issues and identify root causes in complicated systems. His work and communication maintain a pragmatic balance between operational speed and stability. He understands the urgency of security fixes while maintaining the caution required to preserve Ubuntu stability.

To drive consensus and resolve blockers, Wesley uses an effective async-to-sync communication loop. He gathers feedback asynchronously and initiates synchronous meetings to resolve open issues, repeating this cycle until resolution is reached. We recently experienced some friction while establishing a new package publication process. Throughout this, Wesley provided candid feedback and allowed for iterative adjustments, keeping the work moving forward without creating undue high-pressure situations. Furthermore, his collaboration has helped coach my engineers in adopting proper SRU packaging habits.

Areas of improvement and next steps

I have little improvement feedback to give that’s relevant to SRU work. I look forward to Wesley instilling more of the SRU mindset in my team as well as guide external partners with his precise discipline and care.

I think getting upload rights is a great next step for him so that he can officially bring his high standard of engineering and communication to a broader assortment of packages.