FESCo election: Interview with Miro Hrončok (churchyard)

Originally published at: https://communityblog.fedoraproject.org/fesco-election-interview-with-miro-hroncok-churchyard-4/

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

Interview with Miro Hrončok

  • Fedora Account: churchyard
  • IRC: mhroncok (found in #fedora-python and #fedora-devel, although you can find me in many others: #fedora #fedora-3dprinting #fedora-ambassadors #fedora-cs)
  • 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 three 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 Packager 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.

And lately, I’ve been trying to get more involved in packaging for EPEL 9 Next, so I can help bootstrap and maintain some of the essential Python tools for CentOS Stream 9 and to allow future EPEL 9 packagers to enjoy the benefits of the ever-improving Fedora Python RPM packaging.

Fedora ELN brings RHEL engineering more closely into Fedora. How do you feel we should balance RHEL engineering with the community with ELN building from Fedora?

I am very proud of the upstream shift that we have seen in RHEL 9 development and even more excited about the possibilities for the future. I think delivering changes in Fedora first should be the only encouraged workflow, as exceptions to this rule tend to only bring more technical debt. For example, we still have packages in Rawhide today that fail to build with OpenSSL 3, while they were fixed months ago in CentOS Stream 9.

I would like to see a larger involvement of RHEL package maintainers in Fedora processes and better awareness of our policies and standards. For example, I’d like to avoid situations where RHEL packagers were pushing changes only suitable for Rawhide to Fedora 34 after the Beta release, just because they assumed this is necessary to land them in RHEL 9. Hopefully, this is now getting better, but I will keep doing my best to improve the situation. I’d also like to see more RHEL packagers taking active maintainer roles in their corresponding Fedora components, instead of saying “we maintain this in RHEL, not in Fedora”, and more support from managers for such upstream work.

One thing I’d like to see more of in ELN is leveraging it for possibly breaking changes that both Fedora and RHEL want but Fedora Linux is not yet ready to deliver. For example dropping support for old hardware. On the other hand, I wouldn’t like for ELN to become the space for things that we would not even consider for future Fedora Linux or things that we have already tried and failed in the past.

While ELN is “like RHEL”, I believe it should be governed by Fedora (with RHEL needs in mind), rather than directly by Red Hat. For ELN to remain relevant in RHEL development, it must be useful for Red Hat, but for it to remain a successful forward-thinking project within Fedora, the decision process must remain open. The transparency of the ELN SIG that I see today is a great way to achieve that.

What are your thoughts on Fedora ELN and what are your suggestions in improving it?

See the previous answer. My suggestions to improve it were communicated on the devel mailing list and on various occasions where I met with the members of the ELN SIG:

  • Somebody from the ELN SIG should triage the build (order) failures, so that Fedora packagers don’t need to if they don’t want to. With the recent change of how we build packages in ELN, this is now much better.
  • We need ELN-based CI for Pull Requests. If a packager decides to care about ELN, there is no feedback until the package fails to build (which is too late).
  • I’d like to see the possibility to have dedicated ELN branches, so that packagers that don’t want %if conditionals in their spec files or those that need different CI configuration for Rawhide and ELN can achieve that. However, this is a very complex problem.

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 2020 (from which I adapted some paragraphs for this interview as well).

1 Like