This is a part of the FESCo Elections Interviews series. The voting period starts on Thursday, 28 May and closes promptly at 23:59:59 UTC on Thursday, 11 June.

Interview with James Cassell

  • Fedora account: cyberpear
  • IRC nick: cyberpear (I tend to idle in very many channels, participating in the relevant channel for the task at hand. Here is a small selection. I’m regularly running up against the Freenode “too many channels” limit, as I try to stay informed with all the happenings. , -devel, -buildsys, -cpe, -laptops, -coreos, -meeting-1, -qa, -workstation)
  • Fedora user wiki page

Questions

Why do you want to be a member of FESCo and how do you expect to help steer the direction of Fedora?

I’d like to help be the voice of the community beyond Red Hat. I respect many of the Red Hat employees, but sometimes the priorities of RHEL Program things are too overbearing while being somewhat non-transparent to the community. I’d like to help guide the community to solutions that are beneficial both for Fedora and for RHEL. (Day-to-day, I manage RHEL systems for $dayjob.)

How do you currently contribute to Fedora? How does that contribution benefit the community?

I read most of the threads on fedora-devel list in their entirety, dropping a comment where appropriate.

I tend to lurk in many meetings, speaking up when I have something to add. I’m quite active with Fedora CoreOS and Fedora Cloud. I attend the Workstation meetings regularly. I also help fill out test cases for new releases when time permits.

I’ve been following the minimization effort, and sending occasional Pull Requests to dist-git to either reduce the dependencies or better-document why the deps are there. I’m interested in improving each of Server, Workstation, and Container use cases and do tests with each of these.

How should we handle cases where Fedora’s and Red Hat Enterprise Linux’s needs conflict in an incompatible way?

Ultimately, we should find a solution that solves the needs of both, without undue burden on Fedora.

Modularity was handled poorly, and has many anti-features revolving around not shipping or not exposing the content built. The situation with Fedora 32 has greatly improved things with no default modules. In many was, Software Collections were/are a better solution, especially with the -syspaths sub-package convention to make the SCL behave like a native package.

There have been discussions about dist-git vs source-git. I think dist-git needs to remain the canonical source control, and carry the traditional patches on top of pristine upstream sources. The RHEL 7 kernel “single tarball” approach makes the SRPM useless for making any changes and isn’t really the source code. rdopkg has a very good source-git to dist-git conversion, from the dist-git perspective. Ideally, there would be a tool to reverse the process: a command to translate dist-git into a source-git tree.

I’d like to see movement on the Reproducible Builds effort. Particularly, I’d like to first see the entire crypto stack built reproducibly. My longer-term pie-in-the-sky dream is to have the Fedora crypto stack FIPS certified in the manner of OpenSSL; i.e., the source code itself is certified (not the binaries) as this is the only reasonable way to achieve such certification in a fast-moving distribution. (By the time RHEL get a certification, the certified version is out-of-date and needs patching, so in practice most don’t run the certified code.)

The ELN initiave will help make Fedora more useful for RHEL and other downstreams in general. I’d like to see a move toward build conditionals that put the old fedora in the if case and the new fedora default to the else case, and avoid RHEL/EL/ELN conditionals to the max extent possible.

What else should community members know about you or your positions?

I’m a Fedora Workstation user on my laptops, and I’ve been running it full-time since Fedora 8. I’ve been following fedora-devel@ list since 2006-2007, and I manage RHEL systems as my full-time job: servers and workstations. I’m also passionate about using containers to accelerate systems-integration testing, and use ansible throughout such integrations. I see upstream and downstream perspectives.

Editors note: updated 2020-05-28 at 0035 UTC to add the 5th paragraph under the conflict question.