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

Questions

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.

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 Christian Glombek (lorbus)

• Fedora Account: lorbus
  
• IRC: lorbus (found in #fedora-devel, #fedora-coreos, #fedora-containers, #fedora-iot)
• 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?

The advent of Fedora CoreOS in our community gives us a good opportunity to re-evaluate our build architecture and infrastrucure. The packaging process, for RPMs as well as Containers, still has lots of room for improvement, ranging from easier on-boarding to improved developer experience and documentation, up to technical improvements and a higher degree of automation. As packager and member of the CoreOS Working Group (previously Project Atomic WG), the Container SIG and the IoT WG I have gained insights into all kinds of packaging- and container-related things in Fedora. I now currently intern on the Fedora CoreOS team.

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

• Make Fedora the most used container base image (grow that registry!)
• Make the Fedora Contributor onboarding and development experience a breeze
• Make Fedora the go-to, best-tested community distribution for the Origin Kubernetes Distribution (OKD)

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

• Improve RelEng and Packaging DevExp & Automation
• Endorse Flathub for distributing Fedora-based Flatpak desktop apps
• Embrace OKD & CNCF projects
• Steer towards a scalable operator-based, cloud-native infrastructure

I believe with well-debated technical decisions as well as efforts to document and communicate best practices, FESCo can have a great impact and make for huge improvements in all of these spots.

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 Miro Hrončok (churchyard)

• Fedora Account: churchyard
  
• IRC: mhroncok (found in #fedora-devel, #fedora-python, #fedora-ambassadors, #fedora-3dprinting)
• 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?

One of the most important issues is that we tend to push technically fresh (and often unfinished) solutions we are so passionate about so fast to our contributors that we sometimes forget not only about the developer experience of contributing to Fedora, but also about the user experience of using it.

Most noticeable thing I see in this area is modularity: We rarely talk about anything different and while it is an excellent idea based on very innovative principles, we forget to make sure not to break the distro. We are creating technical debt and enlarging the technological gap between contributors who’ve decided to go with modularity and those who haven’t yet (and we should strive not to turn that yet to ever).

Another thing many have talked about is the Fedora CI. The idea to run integration tests on Pull Requests and Fedora updates is awesome. This may render contributions to Fedora easier than ever. Yet we somehow decided that starting with a complex, one size fits all universal standard test interface that does everything just to write and run those tests is more important than having a trivial way to do this. I’d prefer starting with a minimal viable product before adding so many layers of complexity.

The things in Fedora Engineering are moving forward at great speed towards progress. However, I think we should regularly take a moment to slow down and look back. How are the changes we made affecting the life of an average Fedora packager? Tester? Translator? How does this affect our packaging standards? Is there a buy-in from the community, or is just for the ones involved? What happens if…?

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

I see two main concerns in this question:

First, to keep Fedora on the cutting edge of open source development for Fedora contributors, we must make sure that they can contribute to Fedora as easily as possible. They shouldn’t be blocked on unresponsive maintainers, they shouldn’t be blocked on FTBFS packages they don’t maintain, they shouldn’t be blocked by half of the distro moving to modules without the necessary tooling. As FESCo, we can hardly go and fix all the ignored packages and FTBFSes, but we can decide to make the policies easier for individual contributors. We should make Fedora a more collaborative environment, where one person being on a vacation from Fedora for a year (or forever) cannot block the work of dozens of others. Pull Requests are ideal for this and we might design a procedure for ignored requests other than the tedious nonresponsive maintainer policy. Packages (components generally) are still pretty much owned by individuals. Most of them are awesome and open to collaboration, yet some of them are unfortunately acting like passive blockers or active dictators. We should make sure that nothing in Fedora is private property, but rather implement a collaborative workflow and environment.

Secondly, to keep Fedora on the cutting edge of open source development for people using Fedora as their platform of choice, we must hear from them and/or model their use cases. When considering a change (or the status quo) in Fedora, we should ask how it impacts a Rust developer, a web designer, a Lua hacker, a Linux kernel engineer, a JavaScript student, a Python data analyst, a hardware specialist, a QA engineer, or any other kind of developer. For example, what happens if we deliberately delay a Fedora release for half a year? Will those people get the cutting edge tools they need? Will we provide the tools for them via regular updates or in some other way? How do we achieve it without putting half the distro into a module or telling everyone to use rawhide…? We should figure such things out before making a tough decision.

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 for the distribution, it’s the modularity/non-modularity gap. For our processes, I believe we need to streamline the policy for nonrepsonsive maintainers and propose creating a framework for dealing with actively blocking maintainers. FESCo should assess new Fedora changes not only on the basis of how they are making Fedora superior, but also on how do they affect current Fedora contributors and whether the tooling for them is ready (or at least included as part of the Fedora change). FESCo should also design new policies and procedures to make sure individual contribution is always easy and encouraging, instead of difficult and sometimes even disheartening. This will involve not only technical challenges but also procedural changes.

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 Jeremy Cline (jcline)

• Fedora Account: jcline
• IRC: jcline (found in fedora-devel, #fedora-kernel, #fedora-apps, #fedora-admin)
• Fedora User Wiki Page