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 Miro Hrončok


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

I think that the most important issue the Fedora community is facing at the moment, and will keep facing for the foreseeable future, is not really technical but instead a communication problem of how to talk about our technical changes and challenges. At FESCo level I will continue to work on:

  • enforcing policies that aren’t being followed, which leads to stagnation, fo example problems where nobody communicated failures and breakage in a timely manner;
  • adjusting our policies to reflect community feedback, focusing on better notifications about relevant issues;
  • encouraging Fedora contributors (e.g. change owners) to communicate their intent and impact properly and making sure that the plans are adjusted based on the feedback they get from the community;
  • making it easier to contribute when blocked by nonresponsive maintainers;
  • assuring that impactful changes are communicated through the Fedora Change Process (and, if needed, changing the process itself to make it easier);
  • redirecting technical discussions from FESCo tickets to the appropriate mailing lists (most of the time the devel list), where there’s a greater chance of engaging community members in the discussion.

One of the biggest things that is currently happening in Fedora is Modularity. It has high-impact technical challenges. In my opinion, FESCo must assure that the technical issues our community is experiencing are addressed, even if it means we decide not to deliver certain Modularity features until that happens. I’m quite concerned that alienating a big part the contributor community would be much harder to remedy than not delivering some features in the next Fedora release.

I’ll end this answer in the same way I did in the previous interview, because I still stand by that opinion: 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 affect the life of an average Fedora packager? Tester? Translator? How does this affect our packaging standards? Is there buy-in from the community, or is it just for the ones involved?

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. As an example, I believe we’ve managed to make it easier to unblock contributors when it comes to nonresponsive maintainers or packages that fail to build from sources. As FESCo, we can hardly go and fix all the ignored packages and build failures, but instead we have made the processes easier for individual contributors by adjusting the existing policies. We should continue in this and strive to make Fedora a more collaborative environment. One thing that I would like to see changed, is that packages or modules (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 road blocks, rather than experts open to suggestions. We should make sure that nothing in Fedora is private property, but rather implement a collaborative workflow and environment.

Throughout my past year at FESCo, I’ve helped to change some of our policies to improve the situation and I’d like to continue to do so.

Secondly, to keep Fedora on the cutting edge of open source development for people using Fedora as their platform of choice, we must try to hear from them and 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 telling everyone to use COPR or rawhide, without exhausting our contributors? And so on. We should figure such things out before making a tough decision.

During my past year at FESCo, I’ve asked myself such questions when approving or rejecting change proposals or other kinds of tickets. In several cases, I have even asked the change owners similar questions.

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, I think it’s the modularity/non-modularity gap between people. For our processes, the nonresponsive-maintainers and fail-to-build-from-source / fail-to-install policies have been recently adapted, as they needed improvement the most. But the job is never done, we need to keep looking at these polices and adapt them to make Fedora not only a healthier tech stack, but also a healthier community. 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 planned as part of a Fedora change).