Fedora Engineering Steering Council badge, awarded after Fedora Elections - read the Interviews to learn more about candidates

Fedora Engineering Steering Committee

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

Interview with Adam Miller (maxamillion)

  • Fedora Account: maxamillion
  • IRC: maxamillion ,#fedora-releng,#fedora-devel,#fedora-qa,#fedora-cloud,#atomic,#ansible,#ansible-devel
  • 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?

I believe some of the largest challenges we are continuing to face are around Fedora Modularity, Fedora Atomic Host, Factory 2, Fedora CI, container technology, and how each of these works together to more rapidly deliver next generation system architectures. Each of these items are extremely exciting and will bring a lot of flexibility to Fedora and its users but it’s going to require a considerable amount of work and coordination across the community to be able to accomplish. The insight I believe I am able to bring comes from my background in the technology space. I’ve been working on container technology for over 5 years, starting with the original architecture of OpenShift which carried its own SELinux sandboxing+cgroups container technology before things like LXC were mature and before Docker existed. I’ve continued on in the container technology lineage now into the modern era of OpenShift based on Kubernetes. From there I’ve worked directly to implement Fedora’s Official Container Layered Image build system in koji to allow Fedora Contributors to maintain and deliver content as container images, this is also planned to be a method of delivery for Fedora Modules in the future. I also worked on Fedora’s multi-architecture implementation of the Container Layered Image Build System before transitioning that work as I moved to the Ansible Engineering Team, that will allow Fedora to support all hardware platforms with containers that we do with Fedora itself. Another initiative I’ve lead in recent years is Release Engineering Automation powered by Ansible with the goal of enabling Fedora to deliver faster and with more agility. This Automation effort is planned to integrate with the Fedora CI initiative as well. My hope is that the experience I’ve gained working in these areas will allow me to continue to provide guidance as a member of FESCo as we move forward.

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

I think we’re currently on the right track as an over all project with the Fedora Modularity effort and moving towards a Workstation based on Atomic technologies, but that’s thus far kind of been an effort taking place off to the side and I would like to see it come more into the mainline of FESCo and the greater Fedora Community focus. This isn’t only on the shoulders of FESCo, but the concept of moving towards making the operating system more modular and catering to container technologies is something I’d definitely like to see be more in focus moving forward at the FESCo level.

From a community perspective I would like to see FESCo get involved with Fedora Hubs because I think this will greatly lower the barrier of entry for people who want to get started and don’t necessarily know where to look for information and/or don’t know how to connect with the community. I think Hub’s potential to bridge the various sub-projects within Fedora would also be extremely powerful. I don’t know what the best approach for FESCo getting involved here would be but it’s something that I’d love to see discussed.

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 think it all boils down to automation, most bottlenecks in the processes that are used to produce the distribution are there because of a human element or otherwise human requirement to put hands on a keyboard to make something happen. Ultimately the goal would be for everything to be event driven and automated in a way that would allow us to take action on fedmsg messages to drive the creation of Fedora every step of the way. There’s been great strides towards this goal with Factory 2, Fedora CI, RelEng Automation, Fedora Layered Image Build System’s Automatic Rebuilds, and the Modularity Build Service so I think we as a project are moving in the right direction. However, this has proven difficult to implement because we’re now in a situation where not only is the distribution as a whole a moving target that all these teams must chase in order to produce Fedora but also all the processes and tools are changing out from under them. I don’t know of a holistic solution other than we need to be better as a project about being open to the idea of change and being quick to implement it when necessary.