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

Interview with Miro Hrončok

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


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 two years now and I’d like to continue doing 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 work 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 worked with releng to make sure we follow these policies. I’ve worked 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 at 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 think 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 even don’t have an opinion of my own about the proposed change. However, in all the cases, I evaluate the impact of the change on our users — both external (actual 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. Other than FESCo and Python SIG, I am also a member of the Fedora Packaging Committee (FPC), 3D Printing SIG, Xfce SIG, and the new Lua Packager SIG.

As a Python maintainer and a metapackager, I invent and maintain new packaging macros and automation, mostly (but not only) for Python, so 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 proven packager and an active packager sponsor. I’ve been packaging for Fedora since Fedora 17, now taking care of close to 200 packages directly, and much 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 instead of revolutionizing the packaging technology. And second, my goal is to make Fedora the best operating system for developers, especially Python developers, by participating in upstream decision-making processes and making sure that on Fedora everything Just Works™.

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

How should we handle cases where Fedora’s and Red Hat Enterprise Linux’s needs conflict in an incompatible way?

I am a strong believer in close upstream-downstream relationships, whether it’s Python-Fedora, Fedora-RHEL, or RHEL-CentOS. However, such relationships don’t cultivate themselves automatically, they require a lot of work.

Given the nature and history of RHEL and Fedora, the cooperation between the two is well-positioned to create a mutually beneficial environment. Red Hat, as the company behind RHEL, provides invaluable resources to the community to create and maintain Fedora. And in return, the Fedora Project provides a place to develop the future of RHEL. Many RHEL packages are (co-)maintained by their RHEL maintainers in Fedora, but also, many RHEL packages are maintained in Fedora by non-redhatters. Contributions driven by Fedora’s needs will end up in RHEL and RHEL maintainers contribute to Fedora also (but not only) to accomplish their RHEL-driven goals. I sincerely believe that this is an excellent way of creating both Fedora and RHEL and an exemplary showcase of success of not only free software but also open leadership and development process.

With this setup, it is, however, not uncommon that some ideas and projects make sense in Fedora and don’t make sense in RHEL, or vice versa. As with any other upstream-downstream relationship, I believe that we must not fight this, but learn to respect and embrace it to get the best of the two projects. A concrete example from my work: In Fedora, we want to minimize the differences (i.e. number of patches) between our Python and the upstream Python. However, in RHEL, our team has been tasked to make sure Python can be used in FIPS (Federal Information Processing Standards) compliant environments. That currently requires patching Python. Our team members are working tirelessly in Python upstream to make it easier to run future Python versions in a FIPS environment, however, we don’t rush those patches into Fedora just because we need them in RHEL. We realize that the vast majority of Fedora users don’t care about FIPS at all and this change is RHEL-specific. In the end, the Python in RHEL and the Python in Fedora are different: tailored to their use cases.

I also believe that Fedora can only successfully serve as an incubator of ideas for the future of RHEL if we listen to and evaluate feedback from Fedora with an open mind before we introduce new stuff into RHEL. I believe that RHEL-driven development should happen first in Fedora, not simultaneously in Fedora and RHEL. Otherwise, the feedback from Fedora might come too late for us to actually re-evaluate the design. Thus we end up stuck in a loop, where we cannot change anything in Fedora anymore — because it is already present in a released RHEL — and we won’t change anything in future RHEL, because we haven’t changed it in Fedora. I sincerely believe that projects should mature in Fedora first in order to prevail and bring success to RHEL, and I encourage my colleagues at Red Hat not to simply push their RHEL work to Fedora “because that’s what we are supposed to do”, but to leverage the faster life cycle of Fedora in order to develop sustainable projects for stable RHEL.

To sum up: We should embrace the different needs and natures of Fedora and RHEL and use their symbiotic relationship to create two great distros tailored to their specific audiences, instead of trying to pretend that whatever (and whenever) is good for Fedora must be good for RHEL and the other way around.

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. I’d love to see an environment where we don’t see the package maintainers as owners, but rather curators of the content set we provide to our users. I think those two concepts can work great together. Ultimately, I imagine a future where everyone is able to contribute anything, anywhere, pending a semi-automated, semi-manual review from other packagers, without the need for a proven packager or a release engineer to be involved.

You could also read my previous interview from November 2019.