This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, 21 November and closes promptly at 23:59:59 UTC on Thursday, 5 December 2019.
Interview with Justin Forbes
- Fedora account: jforbes
- IRC nick: jforbes (found in #fedora-kernel #fedora-devel #fedora-qa #fedora-arm)
- 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 is no question that modularity is the biggest technical issue affecting the Fedora community at the moment, and probably over the next year. I believe my insight comes from a few places. I was involved with rPath quite some time ago, where we tackled some of the issues that modularity is trying to solve. And as a kernel maintainer by day to day job, I don’t have any particular stake in modularity, so I can view it objectively, with an eye to what is best for Fedora over the long term. I have been involved with Fedora for a very long time, I do have a vested interest in the continued improvement of Fedora and the success and growth of the community.
What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?
Right now, I think working out the issues with modularity should be our top priority, as the current state has become a problem. Outside of that, there is really a long list of details, but it can be all be summarized with “ensure our processes for introducing new technologies are managed in such a way as to not alienate existing contributors, users, and use cases, while publishing stable releases with useful new features”
This includes things like:
- Improving our QA processes
- Taking the time improve our release process
- Ensuring new changes are ready before wedging them into a release
- Making sure changes are not too disruptive to existing workflows.
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”?
Modularity continues to be a trouble spot. It is a great feature in theory, adding capabilities to the distro as shipped, but even more so to people who are using or deploying the distro in their own environments. In practice, it has not been managed as well as it could be. There was always some backlash from the community members who just don’t care about modularity, or understand what it brings, but now there is also justified backlash in how things are being currently deployed. FESCo can help to ensure that further features around modularity are properly planned and executed, though there are a few fires to be put out first.
I also believe we can work to bake more security process automation into our workflow, to ensure that good practices are used for package builds, and CVEs are addressed in a timely manner.