Apologies and So ForthFirst, I would like to apologize for the delay in getting this post done. I really didn't realize the amount of energy the trip would take from me and how fuzzy brained I was for a week afterwords. Second, I would like to thank the Open Source and Standards (OSAS) group at Red Hat for sponsoring me that week. I believe I got a lot of things done and that we can work on getting Extra Packages for Enterprise Linux (EPEL) moving forward in some direction. Third I would like to thank everyone who took the time to talk to me at one of these places to tell me about what they were able to do with EPEL and what they were no longer able to use it for.
One of the items that people brought up a lot was that they felt conversations about fixing/growing/changing EPEL have become a broken record. Various things are said at many conferences by various people, but nothing ever gets done on this to the point that they feel they have been lied to. After succumbing to the fuzzy headed "what did I say yesterday?" for a week after flying back, I think that most of these broken promises have come up from jet-lag and people overload. If it hadn't been that I had people from IBM, CERN, and various other groups bring this up over and over again.. I may have forgotten just as well. In any case, I am going to try and outline every item that I wrote down on many pages of notes in this blog. If I have forgotten some point that you wanted me to bring up, please send me an email so that I can make sure it is dealt with.
Things EPEL is doing well
|EPEL Growth from 2007 til 2016-01|
Things EPEL is not doing well in
- The packaging guidelines for each EPEL version are not clear. This is mainly due to the fact that they are usually based off of older versions of Fedora (Fedora-6 for EPEL-5, Fedora-12 for EPEL-6, and Fedora-18 for EPEL-7) that may conflict with each other or with how things are being done in current EPEL.
- EPEL does not have a regular release structure like Fedora and RHEL have. There isn't an EPEL-5.11 channel with an epel-updates-5.11 where updates are available. Because of various repository limitations, this means that directories aren't able to keep multiple old copies so downgrades when things do break aren't easy.
- EPEL promises to keep things stable and only update for fixes, but this is only done on a few packages where others get upgraded to and fro. There does not seem to be much "steering" or "release engineering" of what is in the trees.
- EPEL only covers part of Enterprise Linux (the Server product) but a lot of packages are for the Workstation but there is no way to see when things replace/conflict with them. [People believe that we build against the equivalent of CentOS-5/6/7 versus a subchannel.]
- EPEL sometimes has weird breaks between releases. The git in EPEL-5 is newer than what is in EL-6 in a way that was breaking repositories when pushes were done from EL-5 systems. [People believe there is a promise that such changes are tested against.]
- EPEL packages disappear. If there is no maintainer packages are retired but if someone is re-building out the EL-5 hosts.. they need that package to be available. [People believe there is a promise that packages will be always available.]
- From various people who were (or former) EPEL maintainers: packages in EPEL are the most complained about. If they can't update the package in EPEL, they get complaints about it being too old and they may end up having a newer version available for what they need to do anyway. If they do update the version, they get complaints that they broke someone because they needed some old version. Most of the complaints usually are the worst kinds ( off-hand death threats (why don't you die in a fire) etc etc).
Things people wanted in EPEL
- Enable 'alternative' architectures. There were requests from people about CentOS-i386 and CentOS-arm (for the Raspberry Pi2 in schools) with no vision on how those would be enabled.
- Enable more packages with shorter lifetimes. One of the things that multiple sites were doing was rebuilding all of a Fedora release for their internal mirrors to supplement all of the things that EPEL didn't have in it. Why can't there be an EPEL-rawhide where all of these packages are built but no 'promises'?
- Is it possible to have a branch management system where packages get updated regularly? Say either whenever Fedora moves to a new release or Red Hat updates to the next branch (6.7->6.8, 7.2->7.3)
- Could packages in EPEL be tested in the CentOS continuous integration infrastructure as part of the autokarma testing?