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