Harvesting the next generation of software for the enterprise
EPEL is a repository of packages rebuilt from the Fedora Project and available for use on RHEL, CentOS, Scientific Linux, and other *EL-based rebuilds. At FOSDEM 2015 there was a hallway session (literally), where we discussed the challenges of EPEL for users and developers, how to work best across the Fedora and CentOS projects, and how the repository should evolve. This session for FOSDEM 2016 intends to build on that discussion with a round-table of key people from EPEL, Fedora, and EL-rebuilds to discuss amongst themselves and with the audience what's right, what's wrong, how to fix, and what the future of EPEL should be.
EPEL has long been the filler gap that makes using an EL-based distro more sane for people not versed in building and maintaining their own packages. Being a curated set of packages, there is a higher trust level expected of the EPEL contributors by the end-users -- a promise that things will go slowly (like the RHEL releases), won't break on minor update (like the RHEL releases), and won't overwrite packages in the base EL distro.
However, EPEL comes from a time when getting packages from your Linux distribution was the best and most trusted way to use vetted and secure software. Software is now delivered in more ways than an RPM package -- containers and cloud images to name two key methods.
With an active relationship between the Fedora and CentOS projects, there have been various proposals about where the build system and repository should exist. In addition, the CentOS Project has layered projects on top of the platform who use the SIG process to provide even newer software for their end-users, where EPEL is often a key dependency. There are a number of technical and social issues to consider in terms of how Fedora as an upstream and the EL rebuilds as downstream need to hold and consume the EPEL bits.
The audience for this discussion are the systems administrators and devops engineers who are end-users of EPEL, either directly or indirectly (because they use a container that builds from EPEL, for example.) They come from myriad situations -- academia, scientific computing, corporations, non-governmental/non-profit organizations, and so forth. Their key similarity is a reliance on the EPEL promise of slow-moving, curated packages and ease of use.
For this audience, the round-table is a chance to tell core EPEL contributors what is going well and what is a challenge in the current setup. It is also a chance to have a front-row seat and input on the future of EPEL from technical and community perspectives. Finally it is a chance for finding solutions with other technologies and forming the communities which can deal with new stuff/slow change.
People we have or are asking to be on the round-table:
- Dennis Gilmore -- Fedora Releng representative
- Brian Stinson -- CentOS downstream representative
- Heikel Guemar or Alan Pevec? -- OpenStack/RDO packager user of EPEL
- TBD -- CERN end-user representative
- TBD -- Scientific Linux downstream representative
- Karanbir Singh? -- CentOS technical and project lead
- Matt Miller? -- Fedora project lead/Board representative
- TBD -- an EPEL packager
- TBD -- another EPEL big end-user
- TBD -- Fedora Packaging Committee member