This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors who are a member of at least one non-CLA group. The voting period starts on Thursday, 21 November and closes promptly at 23:59:59 UTC on Thursday, 5 December 2019.

Interview with Randy Barlow

  • Fedora account: bowlofeggs
  • IRC nick: bowlofeggs (found in #fedora-apps, #fedora-admin, #fedora-noc, #fedora-devel, #redhat-cpe)
  • 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?

There have been many regressions with ease of use for tooling that packagers need to use to deliver software to Fedora’s users over the past few years. Quite a few things are manual now that used to be automatic. As a member of the infrastructure group, I have some first hand knowledge of how and why these changes happened, and I have ideas on how we can improve them.

There is also a project aimed at bringing the CentOS and Fedora dist-gits together in the horizon. I’ve been working on gathering requirements for this project with some other folks, and has potential to lead towards many technical changes being proposed.

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

I think Fedora is more difficult to contribute to than it needs to be. Some of this is due to the usability regressions I mentioned above, but I also think the barrier of entry is fairly high to join the package maintainers. There are some other distributions that allow contributors to simply open pull requests on GitHub, as an example of how low the barrier to entry could be. We, in comparison, require contributors to sign a CLA, submit a package review, perform several practice package reviews, and find a sponsor to join. I suspect that this limits our contributor pool significantly. I think it would be wise to rethink how we operate here, and find ways to lower the barrier of entry for new contributors. One example is to make it easier for contributors to send patches to the project without requiring them to be packagers.

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

As we’ve seen on the devel list recently, there is friction within the community around the modularity project. Some of the issues are technical, some of them are related to policy, and likely most of them are due to misunderstandings of communication and of the project itself. I think FESCo can help here by working to clarify these misunderstandings so that everybody can see the problem statements and proposed solutions more clearly.