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

Interview with Miro Hrončok (churchyard)

  • Fedora Account: churchyard
  • IRC: mhroncok (found in #fedora-devel, #fedora-python, #fedora-ambassadors, #fedora-3dprinting)
  • Fedora User Wiki Page


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

One of the most important issues is that we tend to push technically fresh (and often unfinished) solutions we are so passionate about so fast to our contributors that we sometimes forget not only about the developer experience of contributing to Fedora, but also about the user experience of using it.

Most noticeable thing I see in this area is modularity: We rarely talk about anything different and while it is an excellent idea based on very innovative principles, we forget to make sure not to break the distro. We are creating technical debt and enlarging the technological gap between contributors who’ve decided to go with modularity and those who haven’t yet (and we should strive not to turn that yet to ever).

Another thing many have talked about is the Fedora CI. The idea to run integration tests on Pull Requests and Fedora updates is awesome. This may render contributions to Fedora easier than ever. Yet we somehow decided that starting with a complex, one size fits all universal standard test interface that does everything just to write and run those tests is more important than having a trivial way to do this. I’d prefer starting with a minimal viable product before adding so many layers of complexity.

The things in Fedora Engineering are moving forward at great speed towards progress. However, I think we should regularly take a moment to slow down and look back. How are the changes we made affecting the life of an average Fedora packager? Tester? Translator? How does this affect our packaging standards? Is there a buy-in from the community, or is just for the ones involved? What happens if…?

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

I see two main concerns in this question:

First, to keep Fedora on the cutting edge of open source development for Fedora contributors, we must make sure that they can contribute to Fedora as easily as possible. They shouldn’t be blocked on unresponsive maintainers, they shouldn’t be blocked on FTBFS packages they don’t maintain, they shouldn’t be blocked by half of the distro moving to modules without the necessary tooling. As FESCo, we can hardly go and fix all the ignored packages and FTBFSes, but we can decide to make the policies easier for individual contributors. We should make Fedora a more collaborative environment, where one person being on a vacation from Fedora for a year (or forever) cannot block the work of dozens of others. Pull Requests are ideal for this and we might design a procedure for ignored requests other than the tedious nonresponsive maintainer policy. Packages (components generally) are still pretty much owned by individuals. Most of them are awesome and open to collaboration, yet some of them are unfortunately acting like passive blockers or active dictators. We should make sure that nothing in Fedora is private property, but rather implement a collaborative workflow and environment.

Secondly, to keep Fedora on the cutting edge of open source development for people using Fedora as their platform of choice, we must hear from them and/or model their use cases. When considering a change (or the status quo) in Fedora, we should ask how it impacts a Rust developer, a web designer, a Lua hacker, a Linux kernel engineer, a JavaScript student, a Python data analyst, a hardware specialist, a QA engineer, or any other kind of developer. For example, what happens if we deliberately delay a Fedora release for half a year? Will those people get the cutting edge tools they need? Will we provide the tools for them via regular updates or in some other way? How do we achieve it without putting half the distro into a module or telling everyone to use rawhide…? We should figure such things out before making a tough decision.

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

As for the distribution, it’s the modularity/non-modularity gap. For our processes, I believe we need to streamline the policy for nonrepsonsive maintainers and propose creating a framework for dealing with actively blocking maintainers. FESCo should assess new Fedora changes not only on the basis of how they are making Fedora superior, but also on how do they affect current Fedora contributors and whether the tooling for them is ready (or at least included as part of the Fedora change). FESCo should also design new policies and procedures to make sure individual contribution is always easy and encouraging, instead of difficult and sometimes even disheartening. This will involve not only technical challenges but also procedural changes.