Application - SRU Developer - Seyeong Kim

Community Ubuntu Developer Membership
1

I’m Seyeong Kim and I would like to apply for SRU Developer.

I am applying because:

  • I’d like to help the Ubuntu project maintain stable releases with high-quality updates
  • I want to reduce the burden on existing SRU sponsors by becoming a reliable sponsor myself
  • I’d like to mentor other developers through the SRU process and help them succeed with their contributions
  • I want to continue growing as an Ubuntu developer and give back to the community that has supported me

Who I am

I’m Seyeong Kim, based in South Korea. My Linux journey began in 2001 with Debian, initially as a student user. During university, I started using Linux as my primary development platform and home desktop system. After graduation, I founded my own company and spent several years developing cloud services based on Linux servers and clients.

Beyond work, I have a deep passion for open-source technologies and enjoy exploring various areas of system engineering, from userland applications to kernel internals.

My Ubuntu story

Before joining Canonical, I used Ubuntu extensively for both desktop and server systems throughout university and my startup years. In 2014, I joined Canonical as part of the Support and Technical Services Engineering team. Since then, I’ve been working on a wide range of issues including virtualization, OpenStack, userland server applications, and occasional kernel-level debugging.

Examples of my work / Things I’m proud of

Server and Userspace Bugs

OpenStack Bugs

Virtualization and Infrastructure Bugs

Kernel Bugs

Upstream Contributions

Charm fixes

Areas of work

I mostly work on maintaining Stable Releases as part of my work on the Sustaining Engineering team. I work closely with customers to reproduce and root cause issues they experience in production, and then determine a fix, provide test packages and get patches sponsored and into -proposed for verification and eventual release.

My work spans multiple domains within Ubuntu, including.

  • Userland applications and server packages (postfix, rsyslog, pam, apparmor, autofs, e2fsprogs, bash-completion, debhelper)
  • OpenStack components (Nova, Neutron, Cinder, Heat, Aodh, python-oslo.*)
  • Virtualization (libvirt, QEMU)
  • Infrastructure tools (MAAS, Juju, LXD)
  • Networking (network-manager, netplan.io)
  • System components (systemd, util-linux, sssd)
  • Kernel debugging and fixes

This broad exposure has given me a comprehensive understanding of how different parts of the Ubuntu ecosystem interact with each other, which is essential for assessing SRU impact and regression potential.

Things I could do better

Sometimes I have multiple bugs in progress at the same time, and lower priority issues can remain untouched for longer than I would like while I focus on more urgent customer problems. I am working on better prioritization and making incremental progress on all my open items.

I also recognize that my knowledge of git-ubuntu and gbp workflows could be deeper. While I can use these tools effectively for most tasks, I would like to become more proficient in handling complex merge scenarios and maintaining packages with rich git history.

Additionally, I think I could be more active on public community channels. Most of my communication happens through internal channels, and I would like to maintain a stronger presence on IRC and Matrix to engage more with the broader Ubuntu community.

Plans for the future

General

I plan to keep working on squashing tough bugs, to keep the user experience of Ubuntu as best as it can be. Working with my colleagues to debug tough issues, and giving them advice on Debian packaging and SRU requirements.

As an SRU Developer, I would like to help other developers navigate the SRU process more effectively. I want to become a reliable SRU sponsor who can guide contributors through the detailed SRU procedures—from proper bug documentation and changelog formatting to verification and follow-up. I’m eager to reduce the burden on existing sponsors while helping new contributors succeed with their first SRUs, especially for colleagues in the APAC region who often face timezone challenges when seeking sponsorship.

I have participated in UbuCon Korea several times, and I would like to leverage that experience to help Korean engineers contribute to Ubuntu and navigate the SRU process.

What I like least in Ubuntu

Working with OpenStack packages across Ubuntu Archive (UA) and Ubuntu Cloud Archive (UCA) can be complex. Keeping packages synchronized between these archives requires careful coordination, and the differences in versioning and release cycles sometimes lead to confusion when preparing SRUs. It would be helpful to have clearer tooling or documentation to streamline this process.

Additionally, testing OpenStack SRUs has become more challenging for certain releases. As the test infrastructure has evolved, some releases require different testing approaches or have more fragmented test suites, which can slow down the verification process. Simplifying and unifying the testing procedures across releases would help reduce the time it takes to get fixes into users’ hands.

3 Likes
2

Matthew Ruffell - SRU Developer - Endorsement for Seyeong Kim

Sponsoring feedback

I have worked with Seyeong for about 7 years now, in Sustaining Engineering.
Seyeong is a diligent engineer who has a particular focus on cloud and cloud
deployments. I have been sponsoring Seyeong’s packages for about two years now,
and have worked with him across several uploads.

LP2109673 - sssd
LP2108994 - watcher
LP1960230 - nova (ESM - public)
LP2125818 - nova (ESM - private)
LP2023263 - nagios-nrpe (ESM - public)
LP2112425 - nagios-nrpe (ESM - private)
LP2143377 - manila

Seyeong always goes the extra mile to ensure that all affected releases are
fixed, and that a valid upgrade path exists between the primary Ubuntu archive,
ESM, and Ubuntu Cloud Archive. Sometimes I even tell him that he really doesn’t
have to go back so far, but Seyeong insists on making sure things work
everywhere.

Seyeong has been shadowing me as a part of our effort in SEG to get more
SRU sponsors, and we have a dedicated APAC office hour where we go through
LP bugs waiting to be sponsored. We cover all sorts of uploads, from primary
Ubuntu archive packages, to ESM, to Ubuntu Cloud Archive, and Seyeong actively
engages and takes a part in these sessions. We discuss the pros and cons of
specific fixes, talk about SRU templates in detail, and weigh up the risks
behind each and every change.

Seyeong has really taken to these sponsorship office hours, and the quality of
his uploads have really improved as a result. In the beginning, Seyeong would
take my feedback on very quickly, and would iterate on his debdiffs to make sure
everything is up to spec. Lately, Seyeong’s diffs have been impeccable, and
I haven’t been able to fault them. Seyeong’s judgements when it comes to
sponsoring items from the queue has also been considerate and well thought out.

I believe Seyeong is ready to be a SRU Developer, and I very much believe
Seyeong will be a great help to all of us in SEG, and do a good job. I trust
Seyeong and his judgements, and I trust Seyeong to help pass on his knowledge to
help train more uploaders in the future.

Specific experiences of working together

My latest work with Seyeong is working on LP2143377,
an upload for OpenStack Manila. Seyeong wrote a high quality SRU template,
anticipated my questions in advance and answered them in the template, and
created correct merge requests to the ~ubuntu-openstack-dev git repositories,
as a part of the standard OpenStack sponsorship process.

The merge requests were perfect, all patches have the correct file names,
LP bug tags, dep3 headers, and sponsoring it was a breeze.

Seyeong has seen the value of always building with -proposed and -updates
enabled, in different PPAs, and running autopkgtest before uploading.

Areas of improvement and next steps

For Seyeong, I think the future looks like helping SEG engineers sponsoring
their uploads and improving the overall quality of diffs the team generates as
a whole, as well as heavily supporting the Ubuntu Cloud Archive and keeping
quality high.

I believe Seyeong would also be a good fit for the “UCA SRU Team” aka the
OpenStack Team, such as Guillaume Boutry, and Edward Hope-Morley, performing
the SRU Team duties for the Ubuntu Cloud Archive, of reviewing uploads to
openstack pockets, like epoxy-staging, flamingo-staging etc, and accepting
uploads to -proposed, and eventually -updates. I will keep encouraging
Seyeong to keep thinking about this, because I believe he would be very good
at it.

As for Ubuntu permissions, perhaps Seyeong could work toward MOTU or a limited
packageset permissions for openstack related packages in the distant future.

For areas of improvement, I think Seyeong needs to be a bit more confident
expressing his feedback for people he is sponsoring packages for, especially
putting it into written words things that need to be changed. I have no doubt
he will get plenty of practice with this as he helps sponsor, and as he mentors
new joiners in the team.

Matthew Ruffell 2026-04-07

3

Dariusz Gadomski - SRU Developer - Endorsement for Seyeong Kim

Sponsoring feedback

I have worked with Seyeong for several years in the Sustaining Engineering team. While I was a frequent sponsor for his work in the past, I haven’t personally sponsored an upload for him in over a year. However, I have been closely following his recent contributions and SRU activities—many of which have been sponsored by Matthew Ruffell.

After reviewing his recent uploads, it is clear that the quality of his work has reached an impressive level. His recent debdiffs and SRU documentations are of the highest quality, demonstrating that he has fully internalized the rigors of the SRU process.

In the past, I sponsored several of the items mentioned in his application, which laid the groundwork for his current proficiency:

  • LP#1923115 - systemd: I sponsored Seyeong’s work on the networkd vs udev NIC renaming race condition. This was a complex issue requiring a solid understanding of systemd internals and boot-process race conditions.
  • LP#1886300 - util-linux: I sponsored the fix for the rename.ul regression regarding unresolved links. Seyeong’s approach to identifying the regression and providing a clean backport was excellent.
  • LP#1817651 - netplan.io: I worked with Seyeong on the fix for primary slaves on bonds not being set correctly. His testing for this networking fix was thorough and covered multiple edge cases.
  • LP#1569292 - packagekit: I sponsored the fix for AD domain joining issues, where Seyeong demonstrated his ability to navigate complex userland application bugs.

Specific experiences of working together

Seyeong is a reliable collaborator who often assists in the “heavy lifting” of root-cause analysis for our most difficult customer cases. He doesn’t just apply patches; he seeks to understand the underlying architecture, which is a critical trait for an SRU developer who must evaluate the risk of a change.

His preparation of the systemd and netplan.io SRUs stands out in particular. These are sensitive core components where mistakes can easily break systems, but Seyeong’s attention to detail and rigorous testing gave me full confidence in his uploads. Even looking at his most recent work on OpenStack components and sssd, it is evident he maintains this same high standard.

Areas of improvement and next steps

As Seyeong noted in his application, continuing to build confidence in public community channels and mastering more complex git-ubuntu workflows are natural next steps. However, from a technical and procedural standpoint, he is already performing at the level expected of an SRU developer.

I fully support Seyeong’s application. He has the technical expertise, the necessary caution for stable releases, and a proven track record of high-quality contributions. Having him as an SRU developer will be a great benefit to both our team and the wider Ubuntu community.

Dariusz Gadomski 2026-04-27