This is a part of the FESCo Elections Interviews series. The voting period starts on Thursday, 28 May and closes promptly at 23:59:59 UTC on Thursday, 11 June.
Interview with Igor Raits (formerly Gnatenko)
- Fedora account: ignatenkobrain
- IRC nick: ignatenkobrain (found in #fedora-devel, #fedora-rust, #fedora-python, #rpm.org, #rpm-ecosystem, #koji, #fedora-admin, #fedora-releng)
- 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?
In this role I’d like to help / support community members to build the future (of Fedora and RHEL), make sure that we are not breaking things without reason but at the same time to allow them to experiment, attract more people to contribute and just make Fedora better in all possible ways. I have a deep knowledge of how things work in Fedora in many different areas (RPM, packaging, release engineering, infrastructure) and I’d like to bring this knowledge to the committee.
How do you currently contribute to Fedora? How does that contribution benefit the community?
Currently I am a member of FESCo (seeking re-election, which is why you are reading this text), FPC, Rust, Python, Java, Go and others SIGs and a maintainer of ~3500 packages (either via SIGs or directly). Apart from those «official» positions I am also creating repositories / branches (aka fedora-scm-requests), contributing to the libsolv, RPM, Koji upstreams and many others. I created the Rust packaging ecosystem in Fedora and helped it become a collaborative effort between various Linux distributions (openSUSE, Debian, Mageia). Additionally, I recently wrote an automation that is tracking bugs for non-installable packages. I am trying to make the packaging and maintenance of RPMs easy, scalable and automated, compatible with other RPM distributions and something out of which we can produce many other types of content: containers, flatpaks, ostree and whatnot.
How should we handle cases where Fedora’s and Red Hat Enterprise Linux’s needs conflict in an incompatible way?
I think there is no general answer to this problem. We need to understand that Fedora is the upstream for RHEL so we need to take into account needs of RHEL. Just imagine that upstream of a tool that you happen to use and package is ignoring your problems, you’ll not like the upstream and will most likely stop using / packaging such a tool. I’m pretty sure this won’t happen to Fedora and RHEL, but there might be more and more divergence so that people that are developing RHEL won’t be anymore interested in contributing to Fedora. The same applies the other way around, if people that are working on Fedora decide to change something that will force RHEL to diverge, we should have a good reason. In other words, we need to improve collaboration so that works in both directions.
We have already seen that some changes that were originating in RHEL landed in Fedora just because people were told to do so and how it ended up. We should change this approach to make it easier for people to develop such things in Fedora first, in a way that helps Fedora (or at least has some use) and then become RHEL in a natural way. Do not put things into Fedora just because they are in RHEL.
What else should community members know about you or your positions?
I have been involved in Fedora for more than 7 years, my favorite programming languages are Rust, Python and C and I am happy to answer any questions you may have to me regarding this application or discuss any other topic 🙂