This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 8 December and closes promptly at 23:59:59 UTC on Thursday, 21 December.

Interview with Zbigniew Jędrzejewski-Szmek

  • Fedora Account: Zbigniew Jędrzejewski-Szmek
  • IRC/Nick: zbyszek
  • Matrix Channels typically found in: fedora-devel, fedora-python, systemd, mkosi
  • Fedora User Wiki Page

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

I see the role of FESCo as a place where all voices are heard so that a consensus decision can be reached. It is individual community members, SIGs, and other groups who should propose and implement changes. FESCo is the place where questions about motivation, backwards compatibility, user experience, schedules and contingency plans are asked and answered. I think it’s totally fine when the majority of decisions by FESCo is unanimous after that.

Overall, I think Fedora is doing OK. We are consistently delivering very solid releases regularly, with latest packages, and with a number of interesting new features in each release. The release of F39 was delayed, but this can be attributed to internal Red Hat problems. I hope we’re past this and will be back on track for F40.

To maintain the position of Fedora as the most innovative distro, we need to keep adapting and implementing big new initiatives. I would love to see Fedora more widely used, with more packages delivered more reliably. I very much support the FPL’s goal to double the number of contributors. Coincidentally, I think it’ll be easier to engage new contributors, including existing upstream maintainers, when the packaging story is streamlined.

We have a number of initiatives that improve specific areas, but we’re not doing enough to build tools and procedures that provide a uniform and consistent experience. For example, we have rpmautospec, but it’s not universally used. We have automatic bodhi updates for rawhide, but the same functionality is not available for stable releases. We have gating, but it’s still very hard to use, with lots of false positives. Packit is being used by some packages, but it’s something on the side, only awkwardly integrated with the normal Fedora packaging infrastructure. We need to build a more coherent packaging experience so that we can do bold, innovative things in Fedora.

How do you currently contribute to Fedora? How does that contribution benefit the community?

I’m active in systemd upstream, and I’ve been doing systemd package maintenance in Fedora since 2013; if you’ve submitted a systemd bug in Bugzilla or in the upstream bugtracker, chances are I’ve looked at it. I maintain a few dozen packages, and I try to do new package reviews regularly (469 so far). I’ve been in FESCo since F28. I’be been involved in various initiatives, like the transition of various upstream to Python 3, mass rename of Python 2 packages during the transition to Python 3, improvements to packaging tools (rust2rpm, rpmautospec), transition of the packaging documentation from the wiki, ELF package notes, reproducible builds, updating of Packaging Guidelines for new techniques. I try to help with all aspects of packaging, but I’m especially interested in mass cleanups and automatization of various packaging processes.

How do you handle disagreements when working as part of a team?

Team members must trust each other and be transparent about their reasoning and motivations. If that is true, technical differences can be explained away or proven with actual code. For all this to work, the group must share a common goal.

What else should community members know about you or your positions?

In the same question in the interview one year ago I made a wishlist for 2023:

  • rethink how we use buildroot overrides and side tags (see fedora-devel thread started by Adam Williamson) — side-tags are now the documented way to do multi-package updates, yay!
  • really have reliable gating for package updates — gating has been enabled for rawhide critical-path updates, but in general gating needs more work. The results have too many false positives and the interface makes it hard to figure out what went wrong.
  • embrace rpmautospec — Rpmautospec by Default was accepted and the core documentation has been updated. But many people are still using the old method. If you are in that camp, please come talk to me — I would like to know what is keeping people from switching.
  • embrace SPDX license tags — this is still WIP. Miroslav Suchý and the rest of the team working on this have done extensive work, but we’re only at 60% of packages.
  • work towards reproducible builds of rpms — various ground-level pieces are in place, see the Report from the RB hackfest during Flock. We have a plan to set up a continuous rebuild for rawhide/amd64, but we’re still working on the tooling.
  • work towards unified kernel images and pre-built initrds — this one is important if we want Fedora (and derivatives) to be relevant for confidential computing and other high-security environments. We now have a kernel subpackage that delivers a UKI for VMs, but this approach is hard to scale. Lots of work was done upstream in systemd, but so far this has little effect on Fedora.

My wishlist for 2024:

  • Clean up bodhi update gating so that false failures are infrequent and packagers start relying on the status and always consider the results.
  • Figure out how rpmautospec should be used during initial packaging and during review. The documented method before and after review must be consistent.
  • Convert 90+% of packages to SPDX license tags.
  • Set up a continuous rebuilds of rawhide/amd64 to gather statistics on build reproducibility of Fedora packages. Once the common issues have been resolved, plan towards making build reproducibility an official feature.
  • SystemdSecurityHardening
  • continue the work on Unified Kernel Images and non-dracut initrds. This year we should get a pre-built initrd as an option for normal users.