This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors who are a member of at least one non-CLA group. The voting period starts on Thursday, 21 November and closes promptly at 23:59:59 UTC on Thursday, 5 December 2019.
Interview with David Cantrell
- Fedora account: dcantrel
- IRC nick: dcantrell (found in #fedora-devel, #fedora-qa, and #fedora-ambassadors and other channels for projects I am involved in)
- 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?
- Developer controls for gating and CI. A lot of work has been happening in the context of continuous integration. We created new services, developed processes, and wrote tests. These are all beneficial. I think Fedora needs to ensure we implement developer tools that do not disrupt workflows and which are stable. In my project rpminspect, a Koji RPM and module build analysis tool, I think about developers who are running it to compare builds. A comparison of builds of zlib is very different than comparing two kernel builds, yet I still have a desire to make the tool work for both use cases, so I have added functionality to ensure it will. As we work on projects for gating and CI, we need to keep in mind the broad range and types of software that makeup Fedora.
- Modularity and the many ways we make software available to users. Modularity is a topic that continues to get a lot of attention on the mailing lists. I want to see modularity discussions focus on goals and technical requirements. We can look at modularity as something contributed by Red Hat, a Fedora Project community member. Red Hat had a set of use cases and a deadline. Now we have it in Fedora because Fedora serves as the upstream for RHEL. We should remember that Red Hat relies on Fedora for technical leadership upstream. We should view modularity as a new starting point for a technical discussion on how we deliver software to users. Remember that RHEL-5 shipped with Xen virtualization, and the migration to KVM was worked out in Fedora, so RHEL-6 shipped with KVM.
- Improve integration between our tools and services. I will use the Packit project as an example. Packit is an exciting project because it offers a bridge between upstream development and building for Fedora. And they are interested in improving that developer workflow and making it easier for software to be available in Fedora. Just like Packit, I see tools and infrastructure that we could focus on to improve the experience for package maintainers and other contributors. I would like to see the fedpkg command work for packages that pull their source archives from an upstream git repo. As a package maintainer, I would like to specify a git repo and a tag and then fedpkg take care of the rest. That reduces the work I need to do with dist-git and leaves me more time to focus on bug reports, tracking upstream changes, and submitting patches there. There are a lot of examples like this where small improvements can contribute to improving the developer experience. Fedora needs to treat these problems with a high enough priority to both keep developers interested in working on the project as well as avoiding process fatigue where we feel we have no time to improve things because there’s so much work to do–because we have not improved our tools.
What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?
There is a lot I think FESCo can do here. FESCo should continue to communicate that it is a policy setting body and not a design body. Where a technical decision needs to be made that affects the project as a whole, FESCo should lead that process and get to a conclusion. They do that, but I think this is a definition that bears repeating.
- Release policy. I think it is time to revisit how we define and make releases. There is no question that the release cycle is a significant stress factor for the community. I feel that with the introduction of automated testing services and gating tests, we can discuss redefining what a release means and make more of the development asynchronous. For example, if we were to define Fedora releases as coming from a stable tag in git, release engineering, and QA could trust that building a release from that tag would be usable. Releases could then be happening at any point in time that we see fit. They could be rollups of a dot zero release plus updates. This example is hypothetical, but I think the classic Linux distribution release model is something worth discussing and possibly redefining given our new workflow abilities.
- Contributing changes to upstream projects to help with the minimization effort. I have been at Red Hat for a while, and the topic of “minimizing the install” is a joint discussion for RHEL and Fedora. Nearly all talks end with it being an intractable problem because you have to agree on what minimal means. That goes beyond just defining the files. It also represents functionality. The minimization efforts underway look like good starts, but I would like to see us work with upstream projects to make more functionality conditional at build time if it is not required or contributing support for building with other libraries. For example, if a program includes HTTP download support, but we decide that it is not part of minimal, we should work to contribute patches that let us build it without libcurl (or whatever the library is).
Another example is software with line editing capabilities using readline or libedit. A minimization effort should work to have one line editing library installed, so patches to use that other line editing library help. Too many discussions focus on the built RPMs when minimizing them, but we have made those to enable nearly all functionality and be interdependent. To truly get minimal, we need to think deeper.
- DNF integration with language package managers. I was toying around with this idea earlier in the year, but I think it would be neat to be able to do “dnf install –pip PIP_PACKAGE” or “dnf install –cpan CPAN_PACKAGE.” Integrating these per-language package managers into our system-wide package management could be interesting.
I’m sure I can think of more here, but I have already written a lot of text.
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”?
Aside from everything I have already mentioned, I think Fedora should
be working to improve the contributor experience. Helping a new
community member get started in Fedora is confusing for me, and I have
been doing this for a long time. Having a getting started guide, and
current documentation is part of that, but our tools and services
should be more discoverable for new and existing contributors. I
think FESCo could help here by defining some minimum requirements for
developer tools and services. That could also help identify existing
tools and services we should prioritize to bring them up to a better