This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, 6 June and closes promptly at 23:59:59 UTC on Thursday, 20 June 2019.

Interview with Igor Gnatenko

  • Fedora Account: ignatenkobrain
  • IRC: ignatenkobrain (found in #fedora-devel #fedora-rust #fedora-admin #fedora-releng #fedora-python #rpm-ecosystem #fedora-modularity)
  • Fedora User Wiki Page


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

Packagers do not scale. We do a lot of work to solve technical problems (Modularity, Fedora CI, Flatpaks), but we forget where all of the content these technologies enable come from. We don’t have tooling/processes which ease the life of package maintainers helping them maintain their packages and to deal with all these new technologies.

I have been:

As a FESCo member I would ensure that the changes/decisions the committee is making, will not regress our packagers’ experience and bring important problems/proposals of packagers to the conversation.

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

There is an objective draft, “Packager Experience,” in the wiki and I think it is a very important one. I am planning to revive it and push it forward myself.

In order to keep Fedora attractive for developers (Fedora developers, I mean) and bring more of them, we need to simplify their life with more tooling and automation. Without developers we can’t do much of the innovation that is important for our users.

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”?

Packaging needs lot of improvements. Starting from the Package Review process and all the way through to putting those packages into modules/flatpaks/containers and testing them in CI. Most things there can and should be automated. I’ve spent quite a lot of time on the openSUSE Conference talking to people who are doing Ruby/Perl packaging, the Open Build Service and how they automate things. You can read my report from that conference.

Another thing is: we need to create an easy way how to do PoC of changes outside of “production” infrastructure. Be that staging which allows people to do their tests freely or entirely separate infrastructure is just an implementation detail. For some changes we must ask owners to prepare PoC in this infra, do tests, ask broader audience to try it out (if applicable) and only after that approve such changes. It might feel that we slow down initiatives or just nitpicking, but it is a very important step to find out breakages in early stage and see how such changes will affect other people in our community.