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

Fedora Engineering Steering Council badge

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The  voting period starts on Tuesday, December 08 and closes promptly at 23:59:59 UTC on Monday, December 14th. Please read the responses from candidates and make your choices carefully. Feel free to ask questions to the candidates here (preferred) or elsewhere!

Interview with Adam Miller (maxamillion)

What is your background in Fedora? What have you worked on and what are you doing now?

My history in Fedora technically pre-dates the Fedora Project itself, I’ve been a member of the user community since Red Hat Linux 7 and I still have my boxed set of “Deluxe Workstation” sitting on my book shelf. However, my time as an active contributor to the Fedora Project is far more recent having started during the Fedora 8 cycle when I both became a Fedora Packager and a member of the Fedora QA community.

I’ve been a little all over the place over the years as I learn new things and am able to contribute to new aspects of the project or newer technologies that Fedora is working on/with have become things I find interesting. Below is a list of things I’ve been involved in, including what I continue to participate with and what I’m less involved in these days.

Current activities in Fedora include:

  • Fedora Release Engineering Team Member
  • Fedora Cloud SIG Member
  • Fedora Packager
  • Fedora Proven Packager
  • Fedora Package Sponsor
  • Fedora EPEL SIG Member

Past activities or things I’m less involved in Fedora:

  • Fedora QA Community
  • Fedora QA Proven Tester
  • Fedora XFCE SIG
  • Fedora KDE SIG

Thing’s I’m currently working on for Fedora are largely around Release Engineering, Cloud, and Containers. I’m working with others in the community to clean up “technical debt” around the tools used to actually produce Fedora as well as help to create new ones that help modernize the build and compose pipeline in order to allow the creation of Fedora to be more agile at it’s core. These tools are aimed at catering to the Fedora.Next concept.

I’m also participating in an effort to establish an easier “on-ramp” to Fedora Release Engineering with hopes of making it more welcoming for new community members who take an interest in Release Engineering to join in the efforts and contribute. Much of this is happening in the RelEng Pagure git forge location.

https://pagure.io/releng

Along with this, here are current or recent Fedora Changes I’m participating in:

As of April 2015 I joined the Fedora Engineering Team.

Do you think Fedora should be time based or more feature driven distribution? Or compromise?

This is something that I tend to think we need a nice compromise on. Maintaining a time based release cycle is good for the sake of the users because it makes things like major updates predictable. However, by targeting features we can make sure that we’re delivering releases based on project motivations around features that work towards the future of Fedora. I think we do a pretty good job at this now but am not closed off to the idea of changing it in the future in the event a solid argument for making the change were to present itself.

What are the most pressing issues facing Fedora today (from engineering POV)? What should we do about them?

To me this question is going to be extremely subjective based on the perspective of the person that is being asked. That being said, for me myself I happen to think that our build and compose pipeline is still very rigid which causes our ability to produce new types of “deliverables” (think cloud or docker images, and then whatever is new and cool in 2 years) to be slower than it could be. Also, Fedora is a massive constantly moving target so it’s always a challenge to sanitize that.

What are your interests and experience outside of Fedora? What of those things will help you in this role?

My interests outside of Fedora are operating systems, programming languages, package managers, build systems and systems automation. I know that probably sounds horribly scripted or some kind of really targeted response to an honest question but it’s not, that really is a list of things I find very fascinating and I spend a large part of my free time trying to further educate myself on those topics. These interests in a lot of ways are what lead me to Fedora and why I’ve stayed in the community and plan to for the foreseeable future.

I’m often reading about operating system concepts as they relate to ongoing work in the open source community with the advent of technologies like containers and the ongoing convergence of the linux world around systemd. As a random side note, my favorite books to date in the Operating System space are Andrew S. Tanenbaum’s MINIX (Racoon) book and Robert Love’s Kernel Development book, but I’m always on the lookout for a good one so if you have suggestions I’d love to know about them. 🙂

I also find programming languages fascinating, the different paradigms and semantics are interesting in the way that language creators approach a similar set of problems with different solutions. I spend a potentially unreasonable amount of time reading books and articles about programming languages new and old that I’m not currently familiar with just for the sake of education. I wouldn’t claim to really “know” more than a few programming languages (python being my favorite) but I dabble a lot to try and constantly learn new things.

Package managers is an odd one I’ll admit, but I think it falls under the operating system topic because without a package manager, the OS is relatively boring. I’ve read as much as I can about package managers other than rpm/yum/dnf in an attempt to understand different perspectives on solving the common problem of package management including programming language specific toolsets. It’s mostly a thought experiment as I ponder how we could solve all the problems in Fedora space to cater to system level packaging and user level (including developer toolsets, programming language package management) using a nice unified toolset, but it’s something that I like to think helps keep me on my toes and not stuck with a case a “tunnel vision” thinking only about a single set of concerns around the topic of package management.

My interest in build systems spawned from when I started picking apart how the whole “./configure && make && make install” process actually worked. From there it spawned into an exploration of automake, cmake, qmake, scons, waf and more as well as distributed build systems like koji, obs, buildbot, and others. This also caused a tangent off into the land of continuous integration and continuous delivery, both of which are really interesting topics I enjoy reading about and trying new approaches to as new tools/techniques come to light.

Systems automation is one that goes all the way back to the first time I really learned the true power of the shell (bash). I wanted to script everything and it just flourished from there as an almost obsession with wanting to automate everything. I’m of the opinion that if I can completely automate away my current task set, then I can spend that time working on more interesting things. My favorite automation framework/tool is Ansible, I have some patches in upstream Ansible and even manage my laptop with a playbook.

Anything else voters should know about you?

I live for this stuff, a big part of why I wake up in the morning is because I have an earnest passion for Open Source software. I have a Red Hat Shadowman tattoo on my left forearm that I had even before working for Red Hat. (A picture can be found on my Fedora User Wiki page)

How can FESCo do a better job communicating with the rest of the Fedora community, or do you feel that FESCo is already doing well here?

I don’t inherently think that FESCo does a bad job of communicating, but I think as with all things there’s room for improvement as newer community members or those not as ingrained in the daily processes of Fedora may not always be familiar with what FESCo is doing because they don’t know where to obtain the information. This is also something that Fedora Hubs might be able to help address. However, in the mean time I think FESCo should collectively try to engage with the community instead of being passive about the spread of information, maybe making a point to post regular status updates to the Fedora Community Blog or writing articles for the Fedora Magazine. There’s likely an unclear understanding of the ongoing work that FESCo is involved in.

What can you accomplish as part of FESCo that you couldn’t accomplish as a contributor to Fedora without sitting on FESCo?

I think this largely goes back to what FESCo does, “FESCo handles the process of accepting new features, the acceptance of new packaging sponsors, Special Interest Groups (SIGs) and SIG Oversight, the packaging process, handling and enforcement of maintainer issues and other technical matters related to the distribution and its construction.” such that I believe that not any one Fedora Contributor is any more able to accomplish things within the purview of The Fedora Project than any other, regardless of if you sit on a Committee or not. However, the members of FESCo have the unique opportunity to help shepherd and advise those who are working towards accomplishing specific goals while keeping the technical concerns of the entire project in perspective. I believe that I could participate and contribute in that space.

With the advent of Fedora Council now, what do you see as the significance of FESCO in Fedora project?

I think the Fedora Council’s main goal is to focus on higher level concepts or ideas of the Fedora Project as a whole where as FESCo focuses on the technical implementation or concerns of those higher level concepts. I think a solid example of this would be the Fedora.Next initiative proposed by the Fedora Project Leader, Matt Miller, planned and guided from a high level conceptual standpoint within the Council where as FESCo has and will continue to provide guidance towards and help to enable the technical efforts specific to implementing the concepts of Fedora.Next as well as other initiatives that come from the Fedora Council.

Do you think FESCo can help with the reduction of the backlog of >400 packages awaiting review?

I would like to think that FESCo can, but it’s going to require more than just the small number of people who are a part of FESCo to conquer that many package reviews. This is definitely something that I think falls within the realm of FESCo’s charter to help resolve. Hopefully we can increase visibility on not only the review backlog itself but also that this is a blocker on so many packages waiting to get into Fedora. Possibly the creation of a Package Review SIG that focuses on enabling new packages to make their way into Fedora in a timely manner. This isn’t something that I have a firm answer to but hope that we could collectively focus on to resolve or at least help remedy.

What’s your point of view about library bundling in packages?

tl;dr – I’d prefer we don’t bundle things but I think with the current landscape of the open source ecosystem, it’s something that we need to be able to compromise on.

Library bundling is something I think is a bad idea. That being said, we don’t live in the same world we did in the late 90s and early 2000s where the primary method of acquiring software is the distribution’s repository. Upstream projects used to release source code and expected users to build from source or relied upon downstream projects such as Fedora to consume them and deliver consumable versions of their software with whatever policies around things like bundled libraries that went along with that project. These days it is very common for upstream projects to distribute binary releases themselves with the goal of targeting as many distros and/or platforms as possible. As a side effect of this, bundled libraries has become increasingly commonplace. I think that we should absolutely work towards debundling things that are bundled where applicable but the reality is that some upstreams have no interest in this and are not receptive to the changes. With that in mind, we can either maintain a fork or find a way to manage and mitigate the impact of bundled libraries in Fedora, which is something I think FESCo recently did very well. This goes along with the mantra of “upstream first” such that we engage with upstream projects and communities.