This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Wednesday, January 17th and closes promptly at 23:59:59 UTC on Wednesday, January 24th, 2018.

Interview with Zbigniew Jędrzejewski-Szmek (zbyszek)

• Fedora Account: zbyszek
• IRC: zbyszek #fedora-devel, #fedora-python, #systemd
• 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?

In recent times Fedora has undertaken multiple technical and organizational projects which stretch the available manpower and existing procedures to the limit. One aspect of this is that the scope of the project is simply growing. Both the technologies used to put together the distribution, and the ways in which it is consumed have become much more diverse. This means that it’s ever harder for a single person to understand and follow what all the subgroups in Fedora are doing: we have traditional RPM packaging, flatpak, cloud images and ostree, we have the Modularity effort, we have the three editions, spins, copr, etc. and it is hard to maintain a single community.

When new stuff is added, old stuff does not become irrelevant. Quite the opposite: the new delivery formats build on the existing RPM packaging and build infrastructure. People are still using the reliable install methods to work on the new shiny stuff. But available manpower and human attention is limited and it’s all too easy to regress in existing areas.

Should Fedora encourage new changes or should we slow down to improve what we already have? I don’t think we should slow development down. Fedora always has been about being First, and we are relevant as a place where the development and integration of new upstream projects happens. I think we must continue to absorb new technologies in the distro as much as possible. But we need to this in a way that maintains quality. One way to achieve this is to enforce the Packaging Guidelines and Updates Policy and all the other mechanisms which we have developed to coordinate work. Another complimentary approach is to use existing manpower more efficiently by evolving our packaging and procedures to reduce manual work and use maintainer time more efficiently. We should finish the transition to rpm filetriggers and reduce our use of scriptlets to the bare minimum, finish the transition in Python 2 & 3 packaging and switch to automagically generated dependencies, become the first distro to provide cleanly packaged rust programs, and so on.

I see the role of the steering committee not in driving new initiatives, but in watching for trouble spots and setting requirements so that work done by people who want to implement specific changes integrates smoothly with other work being done in the the distro and does not cause regressions. The areas that need help change over time, based on technical challenges and the amount of energy and time contributors have, and I think FESCo must be prepared to use its authority in two ways: sometimes to slow and constrain certain initiatives to maintain quality, but othertimes to provide help with initiatives that are flagging, e.g. by asking additional people to work on a specific project. To some extent we already have this with the Change process on one side, and “prioritized bugs” on the other side. I think the Change side (i.e. slowing things down by limiting changes to certain time intervals and by settings requirements and contingency mechanisms) is working quite well, but the other side (i.e. finding help) is too weak and does not have enough effect.

One of the reasons why certain changes in the distro take much longer than expected is that they are simply too large for a single person to undertake. Such projects need more than one contributor both to provide enough hands to do the work, but also to provide enough eyes to understand the issue from all sides. But we seem to have trouble with creating such ad-hoc SIGs to implement a specific change. I believe FESCo can take on a bigger role of helping with some technical tasks in the distribution by reaching out to people and groups and facilitating communication. Any time some person or group wants to do something new and things seems to be going well, but ultimately fizzle out because changes in another area of the distro are needed but never seem to happen — without a visible reason — I consider this a failure in leadership and something that this powerful elected committee can help with.

Taking on a bigger role like this means that FESCo must ask hard questions and set requirements on changes. If I’m elected, my goal will be to help people who want to drive changes in Fedora, but to do it in a way that includes public discussion and takes all stakeholders into account.

The growth in the number of variants of Fedora and consumables we produce means that we must have better continuous integration in order to maintain quality. We should finalize the work on package tests and rawhide gating to the point where a package which is pushed out to users is almost certain to work in the common cases. The number of false positives from out automated tests needs to be reduced, and it must be easier for maintainers of packages to add tests for their packages. As I’m writing this, gating is about to be enabled in bodhi. This is great, and FESCo should encourage widespread adoption and implementation of tests.

Through my work on systemd I’m involved in the “bowels” of the distro, and I think I have a pretty good understanding of how various pieces fit together. I’m prepared to spend the necessary time to understand the technical details involved

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

I think the time is ripe for an atomic update mechanism. We have a number of contenders — Atomic Workstation for the whole distro, flatpaks for applications; the Modularity effort. In my own corner, systemd RootImage=/DynamicUser= provides related functionality that could be used as a basis to have services which are isolated and could be atomically upgraded, but which don’t use any virtualization. All those technologies are extremely interesting, but not yet quite ready for the common user. Of course FESCO cannot be doing development, but it should have overview of the changes and make sure they are introduced in a backwards compatible way.

My own pet feature is the adoption of protections provided for system services as systemd unit features. This has been discussed in FESCo [6] and in FPC [7], but the guidelines are just the beginning, and the real work is in updating all ~1200 service files in Fedora. I hope FESCo can lead and coordinate the effort, and that those protections will make us less reliant on SELinux as a security mechanism.

An issue that comes up around every new Fedora release is broken updates due to packages messing up Obsoletes and Provides. In theory the technology to do this correctly is there, but in practice we get it wrong every time. We need to introduce some mechanism so Obsolete everything that is gone from the distro and add testing so that the upgrades work as expected.

I already mentioned the need to finalize the transition to rpm filetriggers to simplify packaging, and the Python 2 & 3 transition. I’d love to see those two initiatives finished in the F28–F29 timeframe.

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”?

Sadly, I think the Fedora Packaging Committee is falling behind. I think it’s members are making good technical decisions, when they actually get around to doing them. But there’s a backlog of open tickets for various issues that doesn’t seem to be decreasing. Many FPC meetings in recent months have fallen through with lack of quorum. Last year it took many months for the Rust packaging guidelines to be approved. At least some improvement can be achieved by moving the guidelines from wiki to a version-controlled sphinx or asciidoc sources. I floated an example proposal to move to sphinx, and it seems that this might finally happen, but so far still nothing has been decided. I think FESCo must push FPC towards modernizing procedures, making it easier for external contributors to contribute to the guidelines, and for FPC members to address the backlog of tickets, in particular by committing to a certain level of participation. I hope the FPC can become more proactive and responsive to various proposals and modernize the guidelines in parallel with the changes that are happening elsewhere in Fedora.

We are not absorbing enough new contributors. I think there’s interest in participation, as shown for example by the long queue of first review-requests seeking a sponsor and people asking questions on IRC. But the whole process is opaque and discouraging. The number of people working on Fedora is not growing proportionally to the size of the distro and our userbase. We are getting better at scaling things, so we get by with the same number of maintainers, but to make our distro relevant in more areas we need more people. We can:

• make the guidelines easier to use, the first step towards which would be the modernization of FPC procedures described above.
• improve the tooling so that semi-automated packaging and semi-automated reviews are easier and more meaningful.
• adopt a general policy that whenever our tooling produces an output that requires manual fixups, but it could be improved to do the right thing automatically, we should consider this a bug. By this I mean everything from bogus rpmlint and fedora-review output through packaging templates and rpm functionality to fedpkg update and the web interfaces,
• simplify the process for new contributors, for example by assigning sponsors automatically, as proposed in the past (e.g. by Miroslav Suchý [2]). I don’t know how exactly the new procedures would look like, but current approach needs to change.
• replace current generic requirements for new contributors by a set of concrete steps, outlining what exactly is required, so that people can just start working on it without asking and seek a sponsor in the meantime. The whole process should be less like apprenticeship and more like an online academy. This might be more boring, but it’ll make the process easier to scale.

Last, we have a number of packages do not build correctly (FTBFS). In the past such packages would be retired after a release was branched, but for various reasons this hasn’t been happening recently. In principle all such cases should have a bugzilla entry, but somehow it’s easy for packages to be broken for a long time without anyone seemingly caring. I don’t think we should mercilessly retire such packages — instead we should leverage koschei and koji results to make such packages more prominent and attract proven packagers and new maintainers to fix such packages. Maybe “adopt a failing package” should be promoted as yet another way to become a contributor.