This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors who are a member of at least one non-CLA group. The voting period starts on Thursday, 21 November and closes promptly at 23:59:59 UTC on Thursday, 5 December 2019.

Interview with Zbigniew Jędrzejewski-Szmek

  • Fedora account: zbyszek
  • IRC nick: zbyszek (found in fedora-devel, #systemd, #fedora-rust, #fedora-python, #fedora-neuro)
  • Fedora user wiki page

Questions

Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?

We have plenty of new stuff happening in package creation and
delivery: automatic generation of build requirements and reuse of
upstream project metadata, new packaging macros, rawhide gating,
library ABI checks, packaging automation like Packit and Modularity,
more CI capabilities, rawhide side-tags and gating, new delivery
formats like Silverblue, containers, flatpaks, modules. The challenge
is how to integrate those technologies into existing workflows so that
the old approaches can coexist and be gradually replaced; how to allow
hawkish packagers who are ready to switch to the latest and greatest
to move forward quickly, without breaking workflows of more
conservative maintainers. We also need to keep in mind packaging
outside of the core distribution: copr users, spins, distributions
which rebuild our packages, people who maintain in-house packages.

We declare that allowing people to build solutions on top of Fedora is
our goal, and we need to weigh the changes that we introduce in this
light.

FESCo does not have the ability to tell people what to do. It is only
useful as a place where questions are asked, and voices of interested
parties are recorded. As a FESCo member my goal will be to ask
questions and gather feedback until any given issue is clear. We can’t
achieve unanimity, and we can’t always satisfy everyone, but we need
to anticipate problems and minimize disruption while still allowing
the technology to move forward.

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

In the next two release cycles:

  • Make gating finally widely used, by concentrating of general tests
    that are applicable to a wide range of packages, to catch
    install/uninstall/upgrade issues, library ABI compatibility breaks,
    missing dependencies. This will make packaging more robust, and empower
    packagers to move on to more interesting tasks.
  • Finish the transition to Python 3, keep only those Python 2 packages
    that we absolutely must.
  • Transition to Java 11 and make the Java ecosystem healthy again.
  • Figure out how to enable the good parts of Modularity, as implemented
    now or as equivalent functionality, without making things difficult for
    everyone else.

On slightly longer scale: automatize packaging of language-specific
stacks like Python or Rust by reusing upstream metadata and making the
package creation and update mechanism as simple as possible. Make the
flow from upstream releases to distro packages fully automatic.

What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those “trouble spots”?

No big surprises considering what I wrote above: we have a lot of
friction where new technologies are being introduced, and the new
conflicts with the old. Not every project that is brought forward is
ultimately worth integrating in Fedora, and FESCo should ask hard
questions and require contingency plans and coordinate reverts if need
be.

Another problem is the stagnation or even shrinking of the number of
contributors. I believe the technical problems discussed above are
significantly contributing to this: the “packaging story” is nowadays
much more complicated and uncertain and less documented than it used
to be; at the same time many experienced packagers are busy fighting
fires and fighting on the mailing lists, so we don’t have time for
newcomers and docs and polish. This is a problem now, but the upside
is that once those pressing issues are be solved, the experience for
new packagers will improve and we can hope to grow the project again.