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 Petr Šabata
Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?
Fedora’s been accepting major and often breaking changes at a very fast pace in the most recent releases. This is not a bad thing per se as it means we’re constantly moving forward. However, I feel many of these are still not very well understood, documented, or socialized. The community as a whole needs more time to adapt and learn how to work in the new environment and with the new tools. Improving contributor experience with the distribution should be our main goal. Since I’ve been directly or indirectly involved in many of these, I could provide the necessary guidance to help rectify the situation.
What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?
I would like to see Fedora as the main and the default development and testing platform not only for our projects but for upstreams as well. The new objective focused on improving our images and tailoring them for specific workflows could be the thing we need to get us there. The best thing is we already have the technology and policies to make us successful — we just need to be smart and use & enforce them wisely, focusing on the weakest links first.
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”?
At present this would be modularity. The tooling is still lacking in many areas, the processes underdefined, the concept still not widely understood or accepted. Yet, modularity is part of Fedora (and it’s a good thing!) and the remaining issues must be resolved. FESCo’s been already looking into many of those problems, be it content discovery, lifecycles, making modular content available in the standard buildroot, or enabling EPEL 8. The work needs to continue so that the objective can be finally closed within the next release or two.