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

Interview with Petr Šabata (psabata, contyk)

  • Fedora Account: psabata
  • IRC: contyk (found in #fedora-devel, #fedora-modularity, #fedora-admin, #fedora-releng, #fedora-perl, and more)
  • Fedora User Wiki Page

Questions

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

Modularity is definitely one of the largest changes to how we develop and distribute Fedora in the recent years. Offering multiple versions or variants of software turned out to be fairly challenging to virtually everybody involved in the pipeline, from package maintainers and QA to infrastructure, release engineering and package managers.

In order for this project to be really successful and make Fedora more appealing to both developers and consumers, it must be made easy for our contributors to opt into. Creation and long-term maintenance of modules must be simple, not confusing, and mostly automated.

I’ve been a Fedora contributor for over eight years now and have been actively involved in the Modularity initiative since its inception. There are still many open questions that need to be resolved, especially with respect to the build and software management tooling. As a FESCo member I would ensure the committee is well informed on these matters and can do the right decisions to push the project forward.

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

Besides the already mentioned Modularity project objective which should lead to more software being available in any given release, I believe our focus should be on improving the quality of our software and more automation of every aspect of our pipeline.

Automation could contribute to catching bugs early and lessen the package maintenance burden. FESCo should help identify the weakest points and support projects aiming at making this happen.

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

I might be one of the very few people who actually believe most, if not all of our processes make sense and are necessary. Some of them could still be simplified by proper tooling – be it reviews (packaging, code, or legal), building or testing.

One of things that is bothering me and is potentially discouraging new contributors is the sheer amount and fragmentation of packaging rules and guidelines. While I understand the good intentions behind these and believe that giving SIGs the freedom to define their own guidelines is generally a good thing, there’s definitely some room for improvement. Generalizing and unifying the necessary rules and splitting rest into best practices documents would probably help.