Originally published at: FESCo election: Interview with Zbigniew Jędrzejewski-Szmek – Fedora Community Blog
This is a part of the Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Monday, 9th December and closes promptly at 23:59:59 UTC on Friday, 20 December. 2024
Interview with Zbigniew Jędrzejewski-Szmek
- Fedora Account: Zbigniew Jędrzejewski-Szmek
- 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?
Continue my wishlist of 2024 into 2025, as I have done in previous election years:
- 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.