This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, December 6th and closes promptly at 23:59:59 UTC on Thursday, December 20th, 2018.
Interview with Justin Forbes (jforbes)
- Fedora Account: jforbes
- IRC: 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?
Fedora is a constantly evolving distribution. Fedora 29 is not just Fedora Core 1, or even Fedora 20 with newer package versions. Big changes happen, and they are typically for the better, but how they are introduced has to be mindful of existing contributors, users, and use cases. Modularity continues to be a major initiative, with a lot of benefits, but also plenty of pitfalls to avoid. We also have the ideas around release cycle, and how Fedora can improve the release process to keep managing things going forward without constant duct tape and string holding it all together. It is often heroic efforts that make a release come together, but that can be improved upon.
What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?
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”?
I am afraid Rel-eng is going to crack at some point. The load they have taken on is massive. It has come in the form of little things here and there that have mounded up to a difficult workload to manage. FESCo needs to both come up with a way to help make it more manageable (the idea has been floated of extending a release cycle), and ensuring we don’t get back into the situation. QA is hitting similar issues, we keep adding releases. This one is a bit more difficult to “fix”
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 planned and executed, though there are a few fires to be put out first.