Application - Core Developer - Nadzeya Hutsko

Community Ubuntu Developer Membership
1

Application - Core Developer - Nadzeya Hutsko

I, Nadzeya Hutsko, apply for Ubuntu Core Developer.

Contact Information:

I am applying because

  • My work is almost entirely in main. Merges of many packages like bash,
    vim, shadow, adduser, tzdata, SRUs, FTBFS fixes, and several
    transitions like the poppler one are not covered by MOTU, so MOTU would not
    reduce the sponsorship I need. I understand that applying directly for Core
    Developer is unusual and I am happy to be judged on that basis.
  • Much of what I send for review does not really need reviewing. No-change
    rebuilds, one-line FTBFS fixes and transition follow-ups make up a large share
    of it. Reading those is not a good use of a core developer’s patch pilot time,
    and I would rather spend that goodwill on the changes where a second opinion
    genuinely helps, which is where I would still ask for one.
  • I’d like to eliminate delays in transition work. During the poppler
    transition every reverse-dependency fix had to wait on a sponsor, which made
    it hard to sequence uploads against the moment the new poppler binaries were
    published.
  • I’d like to be able to sponsor and review the work of others. I would like
    to mentor others and review merge proposals with the ability to sponsor
    uploads, and to take patch pilot rotations.

Who I am

I first became interested in Linux and free software around the age of 17, when
I started exploring different operating systems, including Debian and FreeBSD. I
studied pure mathematics at university and am now studying computer science,
which fits my interest in systems, compilers and tooling. I also worked as a
network engineer, and I remain curious about networking technologies.

I am an Ubuntu Contributing Developer since March 2026. I am also a Debian
Developer, uploading, since June 2026, having been a Debian Maintainer from
November 2025, working mainly with the Debian Rust Team on libraries and binary
crates and Rust transitions.

I have worked for Canonical since July 2022 and joined the Debcrafters team in
November 2025.

My Ubuntu story

My first Ubuntu contribution was in 2024, on rust-hwlib: a Canonical-authored
Rust tool that needed to get into main. That single package turned out to be a
tour of most of Ubuntu’s processes: NEW review, the MIR process, a security
review, an AppArmor profile, autopkgtests, forming a distro team, seeding, and
finally promotion. It took the better part of a year, including a security NACK
and a rejection from the NEW queue :skull:

Since joining Debcrafters in November 2025, I have worked on merges, SRUs, MIRs,
FTBFS and proposed-migration fixes, feature freeze exceptions, and, most
recently, on library transitions in both Ubuntu and Debian.

Away from packaging, I wrote a spec for restoring translated package
descriptions (DDTP) in Ubuntu, which have been broken since bzr was retired from
Launchpad and nobody had picked it up:

The full record is at:

Examples of my work / Things I’m proud of

Library transitions

poppler 26.07, which I drove in Ubuntu first and in Debian afterwards.
poppler bumps its soname every monthly release, and 26.02 through 26.07 also
reshaped much of the internal C++ API, so most reverse dependencies broke for
reasons unrelated to the soname itself.

glew, where I worked through the remaining reverse dependencies:

libjpeg-turbo

gtk2 removal

  • urfkill (MP #503229). Dropping
    the NBS build dependency on gir1.2-gtk-2.0 exposed two older bugs that had
    never been reachable before, which I fixed in the same upload

Main Inclusion Requests

Six MIRs driven, three finalised into main:

Package Bug Outcome
rust-hwlib LP #2072561 Promoted. NEW review, MIR, security review, AppArmor profile, autopkgtests, distro team, seeding
roman-numerals LP #2110098 Promoted, in collaboration with the original maintainer
libfile-libmagic-perl LP #2142465 Promoted
libgav1 LP #2158712 MIR ACK and security review done
libavif LP #2130005 In review
rust-rav1e LP #2133869 Retired, as another package in main provides this functionality

Stable Release Updates

  • tree (LP #2113790)
    across questing, plucky, and noble. I set the bug verification-failed myself after finding that the first patch segfaulted in XML output, had the jammy upload removed from -proposed, and re-did the SRU with a corrected patch rather than shipping the broken one.
  • tzdata 2026a (LP #2143355) for noble and jammy, and through the ESM process for focal, bionic, xenial, and trusty, shipping the new upstream release.
  • python-tz (LP #207604) for focal, bionic, xenial, and trusty as a prerequisite for autopkgtest coverage of the tzdata SRU. My first attempt went to the SRU queue and was correctly rejected because focal is ESM, and it landed through esm-infra instead.

Merges and syncs

Merges, mostly main packages and several with substantial delta:

Syncs, where the Ubuntu delta had become unnecessary and the package could come
straight from Debian:

The transitions above account for further syncs, including spring, gdcm,
pdf2djvu, openboard and popplerkit.framework.

Autopkgtests

  • libavif (MP #502116), enabling the upstream test suite at build time and adding autopkgtests, written for the MIR and since adopted in Debian 1.4.0-3, so the Ubuntu delta can be dropped
  • libgav1 (MP #507578), new autopkgtests, also for the MIR, forwarded to Debian as salsa MR !4
  • rust-hwlib, a DEP-8 test that mocks the hwapi server so the client can be tested without network access, which was one of the MIR requirements
  • tree, extending d/t/clitest.md to cover the SRU fix
  • py3status, where the clock test itself was the problem and needed a longer timeout alongside the code fix

+1 maintenance, FTBFS and proposed migration

+1 maintenance shift report, 2 to 6 March 2026:

Build failures:

Proposed migration:

Feature freeze exceptions

  • LP #2145012:
    sync dracut 110-6, granted by the release team with the condition that it
    migrate before beta.
  • LP #2148194:
    a new overlayfs-crypt dracut module for LUKS-encrypted persistent overlays,
    part of porting overlayroot to dracut.

Tooling, archive infrastructure and review

  • ubuntu-dev-tools: reverse-depends silently printed nothing when all
    results were filtered out (0.210).
  • ubuntu-archive-tools: registering a distro team, a prerequisite of the
    rust-hwlib MIR (MP #485759).
  • Reviewed a community contributor’s first FTBFS fix for unity
    (MP #500983),
    then prepared a version that fixed all the build failures, crediting their
    work in the changelog.

Debian work that (I think) matters for Ubuntu

I list this because a good deal of what I fix for Ubuntu is fixed in Debian, so
that Ubuntu can carry no delta at all. My Debian packages are at
https://qa.debian.org/developer.php?login=nadzeya.

  • After the poppler 26.07 transition had gone through Ubuntu, I requested it in
    Debian as well and drove it there with the release team. Several reverse
    dependencies were fixed in Debian rather than in Ubuntu and then synced back:
    popplerkit.framework, openboard, pdf2djvu, gdcm and ipe-tools.
    Ubuntu came out of the transition carrying less delta than it went in with.
  • tree (Debian #1118451), libavif and
    libgav1 fixes were forwarded to Debian for the same reason, and the
    libavif autopkgtests have since been adopted there.
  • In the Debian Rust Team I maintain a set of library and binary crates, packaged the Debian way with debcargo. Ubuntu takes the opposite approach for anything heading for main, vendoring the crate sources into the one source package so that hundreds of individual crates do not each need a MIR. Knowing both models is useful as I think it is what let me update the vendored Rust packages in main, rust-hwlib and rpds-py, and it makes me quick during +1 maintenance on the much larger set of Rust packages in universe, which are debcargo-style and do not vendor at all, such as rust-bytemuck, rust-scratch and rust-libheif-sys.

Areas of work

I work in the Canonical Debcrafters team, mostly on main packages, and in the
Debian Rust Team.

People I have worked with most closely:

  • Sponsorship and review: Nick Rosbrook, Sebastien Bacher, Simon Chopin, Lukas
    Märdian, Benjamin Drung, Graham Inggs, and Lena Voytek.
  • Main inclusion: Christian Ehrhardt and the rest of the MIR team, and the
    security team.
  • Uploads outside my own team: Jeremy BĂ­cha, Gianfranco Costamagna, Vladimir
    Petko, Lukas Märdian, and Pragyansh Chaturvedi
  • Debian: Dmitry Shachnev on roman-numeralsand the release team on the
    poppler transition.

Things I could do better

  • Seeds. I understand the mechanism fromrust-hwlib, but the seed change itself was made by my MIR reviewer rather than by me. I would like to own the next one.
  • Version strings. Three of my uploads needed a sponsor to catch a version mistake, in plocate, openboard and the first tree SRU. None reached the archive, but with upload rights there is no second pair of eyes.
  • Unfinished work. libnbd (LP #2143548) has been open since my +1 shift in March, and kicad(LP #2166847) is still open behind an
    lto-disabled-list workaround.
  • Only one +1 maintenance shift so far, and only three packages SRUed.

Plans for the future

  • Take patch pilot and sponsoring rotations, and more +1 maintenance shifts.
    Sponsoring others is the main thing I cannot do today.
  • Keep doing library transitions.
  • Finish the libavif and libgav1 chain so python3-pil can build with AVIF
    support without an Ubuntu-specific build profile.
  • Continue improving Rust support in Ubuntu and Debian.
  • Broaden my SRU work, and take on network-related packaging.

What I like least in Ubuntu

How scattered the information is. Almost everything a developer needs is public,
which is the important part, but it lives on a different host for every kind of
question, each with its own conventions and none of them talking to each other:

There is no single view of what needs my attention, so keeping track means
checking six or seven places by habit and knowing which one answers which
question. I believe that’s a real cost for a newcomer.

3 Likes
Ubuntu Developer Membership Board Agenda
2

## Sponsoring feedback

I have sponsored several uploads for Nadzeya, and I have always found that she does excellent work. I completely trust Nadzeya to be a Core Dev!

## Specific experiences of working together

I work with Nadzeya on the Debcrafters team at Canonical. I have a lot of experience working with her on general distro work, sponsoring uploads, discussing Ubuntu and Debian processes, and pairing on bug triage.

I have sponsored several merges for Nadzeya, including plocate, adduser, and vim, which is pretty complex. She always does a good job of dropping delta when appropriate, forwarding delta, and generally keeping our delta manageable. Some examples of fixes for proposed migration include py3status and lintian. I have also reviewed and/or released SRUs that Nadzeya has worked on, and it is clear that she has a good understanding of the process.

Nadzeya is also very involved in Debian, which improves her packaging skills and awareness more broadly.

## Areas of improvement and next steps

Just keep building skills and knowledge, and continue to expand involvement in the community. For example, I think Nadzeya will be a great addition to the patch pilot rotation!

1 Like
3

Sponsoring feedback

I’ve been working with Nadzeya for around 1.5 years as part of the Canonical/Debcrafters team. When she joined she was already an active Debian contributor and member of the rust team.

During that time, according to UDD I sponsored around 25 package uploads for her, a mix of merges / SRUs / autopkgtests and build fixes. She understands Debian packaging very well and her work is rigorous and high quality. She also knows Ubuntu processes well and has been working on MIRs, FFes and transitions. She also actively participated in +1 rotation helping fixing proposed migration issues. During that time she also became a DD.

I’ve no doubt she is ready for coredev and that she can be trusted and I’m giving a strong +1 to her application.

Specific experiences of working together

Areas of improvement and next steps

I’m looking forward to having Nadzeya help with patch pilot/sponsoring/+1 rotation which are not only a good opportunity to help Ubuntu but also to share knowledge with our newer members. I think she’s also a great coatch and it would be nice to see her gaining confidence to engage more actively on public channel helping others.

1 Like
4

Paride Legovini

Sponsoring feedback

I believe Nadzeya Hutsko is ready to become a Core Developer right now, and I strongly support this application. The examples in her application show that she can work across the core aspects of Ubuntu development, including merges, SRUs, MIRs, transitions, and proposed migration. She is mindful of how Ubuntu development is done as a whole, and is familiar with the processes a Core Developer may be involved with.

Nadzeya also understands the social aspects of Ubuntu development: working with other developers, engaging with Debian and upstream projects, and keeping in mind the wider Open Source/Free Software community. Her efforts to get fixes into Debian and reduce the Ubuntu delta are good examples of this. I trust Nadzeya both technically and personally with Core Developer privileges and upload rights, right now.

Nadzeya is also an uploading Debian Developer, mostly active in the Rust team.

Specific experiences of working together

While I have not sponsored many uploads for Nadzeya, we work on the same team, and I have had many occasions to be exposed to her packaging work through merge proposal review requests and day-to-day technical discussions. This has given me a broad view of her Ubuntu work.

Nadzeya is actively involved in +1 maintenance and proposed-migration work. As an autopkgtest maintainer, I see how she can tackle non-trivial cases preventing packages from migrating, investigating the underlying problems and working through the fixes needed to unblock them. This work shows both solid debugging skills and an understanding of how individual packages or bugs can affect the wider distribution.

Areas of improvement and next steps

Nothing specific comes to mind that should hold back this application. I would like to see Nadzeya bring the same care to sponsoring and reviewing other contributors’ work, and I think she will be a very good addition to the patch pilot rotation.

1 Like
5

Sponsoring feedback

Specific experiences of working together

  • Lintian merge from Debian unstable

  • Fixes for glew and libjpeg-turbo transitions

Areas of improvement and next steps

  • I’d like to see Nadzeya doing +1 Maintenance and Patch Pilot work ASAP!
1 Like
6

I endorse Nadzeya for Ubuntu Core Developer.

Sponsoring feedback

I’ve primarily sponsored the rust-hwlib package for Nadzeya, when she started her packaging journey. It started off as a super special snowflake, with orig tarball repacking, native versioning, and lack of an owning team. We did plenty of iterations, and the package became better and better with every step! It’s now a clean and well-documented non-native package, with proper DEP-8 tests, no repacking required, and a nicely separated .orig-rust-vendor.tar.xz tarball for the vendored sources.

This endorsement is mostly a repetition of my endorsement for Contributing Developer, but more valid than ever. Looking at Nadzeya’s track-record since joining the Debcrafters team late 2025, shows that she gained very strong packaging experience working through multiple transitions, MIRs and SRUs in addition to plenty of “daily business” packaging work, such as merges/syncs.

Specific experiences of working together

I worked with Nadzeya as a MIR reviewer for rust-hwlib. The bug was tagged needs-packaging originally, as it was a new Canonical project that needed to pass NEW review first. Then we worked through the MIR process, adding autopkgtests and (AppArmor) confinement. We also needed to form a new canonical-hw-cert distro-team and get the package seeded. Overall, it was a very convoluted process that she mastered with ease, passion, and patience! There were lots of hoops to jump through (technical and process-wise), and she was eager to dive into all of it with super-fast iteration cycles.

I’ve also worked with Nadzeya in Debian, where she joined the networking team and we had some very good discussions at DebConf that showed her passion about free software and Debian/Ubuntu specifically.

Areas of improvement and next steps

There are always new things to learn in Ubuntu, and how it differs from Debian. With new powers come new responsibilities, so Nadzeya should learn about dput-ng helpers, such as .dput.d « cpaelzer - ~ubuntu-server/+git/ubuntu-helpers - [no description] that can help to avoid small issues when uploading a package, such as broken version strings :wink: . Helping with +1 Maintenance rotations & patch piloting should help to strengthen her profile even further. She has lots of energy and is picking up new skills at a super fast pace.

1 Like