FESCo election: Interview with Miro Hrončok

Originally published at: FESCo election: Interview with Miro Hrončok – Fedora Community Blog

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

  • Fedora Account: churchyard
  • IRC: mhroncok in #devel:fedoraproject.org / #fedora-devel, #python:fedoraproject.org / #fedora-python, #fedora-3dprinting, many others
  • Fedora User Wiki Page

Questions

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

I have served in FESCo for four years now and I’d like to continue to do so.

At FESCo, my mission is to make sure that our engineering community (Fedora and EPEL packagers and developers, both within Red Hat and outside of Red Hat) are not left out from the decision-making process, that every opinion is heard and everybody has been given space to express their technical opinion.

I also want to make sure that our policies are up to date and serve the purpose they were designed for. If we have a bad policy, we should strive to amend it rather than ignore it or bypass it. In the past, I’ve participated in updating the non-responsive maintainer policy and the policy for packages that fail to build and/or install. I’ve been working with releng to make sure we follow these policies and I’ve collaborated with the Program Manager to amend the Change process to include the feedback section. Work like this is never finished, but I’d like to continue it because it’s necessary to keep Fedora fresh and relevant.

When we vote about changes in Fedora, I always evaluate the feedback the proposal received on the devel mailing list. That’s where I believe most of the discussions should happen instead of inside the FESCo tickets or small private silos. When a change proposal impacts parties that were initially left out of the discussion, I try to circle back to include them. When an already accepted and implemented proposal turns out to negatively impact the work of Fedora packagers, I work hard to return things to a working state once again and to prevent future breakages.

I don’t claim to deeply understand every technical aspect of all the software in Fedora. Sometimes I don’t even have an opinion of my own about the proposed change. However, in all cases, I evaluate the impact of the change on our users — both external (users of the distro) and internal (our contributors).

How do you currently contribute to Fedora? How does that contribution benefit the community?

I work at Red Hat in the Python Maintenance team and I’m a member of the Python SIG. I’m mostly taking care of the Python ecosystem in Fedora as an upstream for RHEL and CentOS. Besides Python SIG and FESCo, I am also a member of the Fedora Packaging Committee (FPC), 3D Printing SIG, Xfce SIG, and the Lua Packagers SIG.

As a Python maintainer and a meta-packager, I invent and maintain new packaging macros and automation, mostly for (but not limited to) the Python ecosystem, so that our packagers can leverage new technical possibilities in the packaging world. I make sure to backport all such improvements to EPELs, whenever technically feasible, to ensure our EPEL packagers can keep maintaining more or less compatible spec files. To make this all technically possible, I am also a provenpackager and I’m actively sponsoring new packagers. I’ve been packaging for Fedora since Fedora 17, and I’m now taking care of close to 200 packages directly and hundreds more through the Python SIG.

I have two overreaching goals. First, my goal is to make the packaging experience better by improving the tools our packagers use. I feel this is more important than revolutionizing the packaging technology. And second, my goal is to make Fedora the best operating system for developers. To that end, I’m participating in various upstream decision-making processes (for example in various projects throughout the Python ecosystem) to make sure that on Fedora, Everything Just Works™.

I am also in charge of the day-to-day execution of some of the not-yet-fully-automated Fedora policies, making sure our package ecosystem remains in a healthy state.

Last year, I’ve been actively packaging for EPEL 9 and contributing to CentOS Stream 9 to allow EPEL 9 packagers to enjoy the benefits of the ever-improving Fedora Python RPM packaging.

How do you handle disagreements when working as part of a team?

In any large team, like the team of all the Fedora contributors, disagreements happen quite often. I believe it is always a good thing to see various aspects of a proposed change or policy and I am always thrilled when somebody disagrees with some details about what I propose, as it allows us to work together and build something that is better for everyone. I prefer constructive negative feedback over no feedback at all.

I believe our job at FESCo is to solicit feedback and triage all the disagreement to distill a decision that benefits Fedora the most. Sometimes, this unfortunately means we cannot have nice things because they are attached to some unfortunate things as well. I believe that in that case, it’s better to go back to the drawing board and propose something that the community can agree on.

Disagreements happen at FESCo as well, but the majority of conclusions is either unanimous or leads to a plan that eventually gains support from all. I believe we are doing a good job.

What else should community members know about you or your positions?

I’d love to see more packagers using the pull request workflow because I want us to test our changes (via CI) before we merge them. And I’d love to see an environment where we don’t perceive the package maintainers as owners, but rather curators of the content set we provide to our users. These two concepts can work great together: Ultimately, I imagine a future where everyone can contribute anything, anywhere, pending a semi-automated, semi-manual review from other packagers, without the need for a provenpackager or a release engineer to be involved.

You could also read my previous interview from November 2021 (from which I adapted most of paragraphs for this interview as well).