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

Interview with Zbigniew Jędrzejewski-Szmek

Questions

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 motiviation, 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. All recent releases has been well received by the press and users.

Nevertheless, I feel that it has become harder to do “new” things. We’re fairly receptive to incremental changes like updates and completely new deliverables, but it’s much harder get acceptance for proposals that rework things and are potentially disruptive. The motivations of people who block or question things are good: we certainly don’t want to break what we have. But I feel like the bar has been raised too high, and even after the proponents of a change show that it will not have a big negative impact, but possibly some small ones here and there, the change is not accepted until a huge effort has been made to discuss each and every possible regression. This makes it harder and harder to innovate in Fedora.

As mentioned above, I think Fedora is currently in a fairly good place, but to maintain this position we need to keep adapting. I would love to see Fedora more widely used, with more packages delivered more reliably. To make that happen, we should automatize packaging: package gating, rpmautospec, semi-automatic updates. 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 hope to use my vote in FESCo to enable people to do bold 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 (463 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 2022. I’m surprised how much progress has happened:

  • transition to SPDX in License tags — yes!, in progress
  • packaging using tools like rust2rpm and the new pyproject macros works for 99% of upstream projects — lots of progress, lots of work remaining
  • rpmautospec — significant progress in fixing various corner issues, but still not the default
  • gating becomes reliable and covers more updates — some progress has been made
  • the sponsorship process for new packagers becomes transparent — nope
  • the docs are cleaned up and updated and searchable — yes, search has been added. Various cleanups have been done.

I plan to submit a F38 Change to document rpmautospec as the default approach.

Items for 2023:

  • rethink how we use buildroot overrides and side tags (see fedora-devel thread started by @adamwill).
  • really have reliable gating for package updates
  • embrace rpmautospec
  • embrace SPDX license tags
  • work towards reproducible builds of rpms
  • work towards unified kernel images and pre-built initrds