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

Interview with Zbigniew Jędrzejewski-Szmek

  • Fedora Account: zbyszek
  • IRC: zbyszek (found in fedora-devel, #systemd, #fedora-python, #fedora-neuro)
  • 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 not as a “leadership group” that drives changes, but instead as a place where all voices are heard so that a consensus decision can be reached. It’s individual community members, SIGs, and other groups that 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. F33 seems to have been very well received by the public.

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. I hope that over the next year each and every package update will 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. Unreadable reporting of test results is currently the weakest part 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, rebase-helper, packit, forge macros, rpm’s %generate_buildrequires, tarball signature verification, pyp2rpm, rust2rpm, rpmautospec, 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.

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

Upstream systemd development, systemd package maintenance in Fedora.
FESCo. Sponsorship of new packagers. I have about 70 packages, but I also help with FTBFS, upgrade bugs, and updates in other packages, esp. Python packages. Package reviews (30 over the last 12 months, 400+ overall).
Contributions to rust2rpm, rpm macros, and other packaging tools. Recently, Fedora Magazine article about systemd-resolved. Various contributions to the FESCo policy documents. I post a lot (maybe too much) on fedora-devel.

How should we handle cases where Fedora’s and Red Hat Enterprise Linux’s needs conflict in an incompatible way?

Fedora and RHEL have different goals and will always be different, without conflict.

The real source of contention is the limited number of hours in each day:
our maintainer resources are stretched thin and this means people want to reuse the same approaches and solutions.

We need to decide what is important for Fedora, and based on that set
clear guidelines what is acceptable. At the same time, we should make
packaging easier, more automated, with less busywork and chances for
mistakes. It should be as easy as possible to reuse the Fedora
packages in downstream projects. Inevitably, there will be cases where
the choices in Fedora and RHEL are incompatible and some things will need
to be done “twice”. In such cases, we need to make sure that our role
as the upstream community distribution is clear and just do our thing.

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

I absolutely love working on Fedora and I hope it remains at the forefront of Linux development.