This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Friday, 26 November and closes promptly at 23:59:59 UTC on Thursday, 9 December 2021.
Interview with Zbigniew Jędrzejewski-Szmek
- Fedora Account: zbyszek
- IRC: zbyszek (found in fedora-devel, #systemd, #rpm-ecosystem, #fedora-python)
- 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?
[Parts copied directly from 2020 and 2019… Clearly some things change slowly.]
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. I see the role of FESCo in making sure that questions about purpose, 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 in a good place. We are consistently delivering very solid releases regularly, with latest packages, and with a number of interesting new features in each release. Each of the last few releases has been well received by the press and users.
The part I worry about is where we go from here: I would love to see Fedora more widely used, with more packages delivered more reliably. To make that happen, we should automatize packaging: we have been working on package gating for a long time, but updates that don’t even install are still being pushed. Each and every package update should go through basic installation/uninstallation/upgrade tests (like Debian’s piuparts). This should be implemented at the global level: individual packages may add custom tests, but the basics should be tested without any additional work. Crucially, if the package fails some test, the results need to be provided in a human-readable manner. Unreliable results and unreadable reporting of failures are currently the weakest parts of our CI story.
Once we have reliable update testing, it becomes reasonable to do package updates automatically. At least for Python and Rust packages we’re moving towards a model where upstream metainformation is fully sufficient to build a package in Fedora (including versioned dependencies and subpackages and package descriptions), and the .spec file is just a thin wrapper. We’ve been hacking away at the problem (with release-monitoring.org, rebase-helper, packit, forge macros, rpm’s %generate_buildrequires, tarball signature verification, pyp2rpm, rust2rpm, rpmautospec, source-git, and so on), but we’re not there yet: packaging involves a lot of manual drudge work. I expect that 80% of packages could be “maintained” through automated updates and testing, freeing our maintainers to spend more time on the remaining “hard” packages, improving tools, and fixing more complicated bugs. I also think automated packaging (not bundling or modules) is the only reasonable way to deal with language ecosystems like Rust or Go where hundreds or thousands of packages are pulled in as dependencies.
To achieve those goals without sacrificing quality, our tooling needs to improve across the board. We also need more people. Coincidentally, I think it’ll be easier to engage new contributors, including existing upstream maintainers, when the packaging story is streamlined.
I think it is important for FESCo to remain receptive to new ideas. For example, I think that the process to switch to Btrfs as the default file system was performed correctly: we discussed things in great detail, but at some point the technical evaluation showed more plusses than minuses, and even though some people still had reasonable concerns, the choice was made and implemented. I hope we do the same with other bold ideas in the future.
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 (436 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, 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.
Fedora ELN brings RHEL engineering more closely into Fedora. How do you feel we should balance RHEL engineering with the community with ELN building from Fedora?
Red Hat is our closest downstream, but over the years the separation between Fedora and RHEL packaging has slowly increased. This is visible in the number of RedHatters who are involved in Fedora packaging — this number hasn’t substantially changed over the years, while Red Hat itself has grown, and the number of packages in Fedora has also increased.
I consider ELN to be a big opportunity for Fedora. It is better for us when the downstream work is done closer to Fedora, when new ideas are hatched in the open and in close cooperation with upstream, and when the pool of people who can help with maintenance in Fedora is increased. The biggest risk with ELN would be if downstream requirements and practices had too much influence on Fedora packaging. But so far this doesn’t seem to be much of a problem: the work that is done for ELN is clearly separated.
I hope that we can keep a balance where anyone who wants to be involved in ELN and/or rawhide packaging can do so, in particular many of the RHEL maintainers who so far were not active in Fedora until now, while other maintainers who only care about the Fedora side can ignore ELN. Such a split has been working just fine with EPEL packages, and I expect the same will happen with ELN.
What are your thoughts on Fedora ELN and what are your suggestions in improving it?
Automatism and smooth rebuilds in ELN are key to keeping the friction with working on ELN to the minimum. A lot of progress has been done in this regard since ELN was initially introduced, but things still occasionally get stuck, in particular with big mass rebuilds. ELN should be completely automatic, and maintainers should only need to get involved when they want to purposefuly make something different than in Fedora.
ELN will prove its worth when the next version of RHEL is released.
What else should community members know about you or your positions?
Things that I expect to happen in 2022 in Fedora packaging:
- transition to SPDX in License tags. (This will help with templated packaging of Python/Rust/Go upstreams, and with licensing reports on Fedora. People in the indistry are excited about automatic verification of licensing, SBOMs and such, and our bespoke licensing language is becoming a hindrance in this.)
- packaging using tools like rust2rpm and the new pyproject macros works for 99% of upstream projects, and we have reliable fully-automated packaging of Rust and Python packages.
- rpmautospec adds the remaining bits so that it is usable for all packages and we can document it as the default solution.
Things that I would love to see, but I don’t see a clear path forward:
- gating becomes reliable and covers more updates, so that updates that break the build root or are plain uninstallable never reach updates-testing.
- the sponsorship process for new packagers becomes transparent and predictable to the all people involved, but especially the the future packagers.
- the docs are cleaned up and updated and searchable, so that people stop saying that it’s hard to find answers.