BackgroundSo my time at FOSDEM was pretty much the following. Walk into the hall where the Fedora/CentOS tables were. Get met by someone who worked on or in EPEL. Try to have a conversation and find that it was too packed and loud there. Walk over to the coffee area and buy the person a coffee and listen. Finish conversation and walk back over to the table.. [take a break every now and then to use the restroom from drinking a 16 oz tea every 30 minutes.] This was a lot of conversations and they did all blur together after a while. [Using a technique I learned from Centos' Karanbir Singh at FOSDEM, I will bring a small notebook to the next conference and write down a problem per page per person. Then I can go back the next year and see if the problems are still there.]
PromisesWhile they all did blur, there were many similar questions from people that came up:
- What are the promises that EPEL makes to its users?
- Do those promises make sense? [Do we need to keep a package the same for 5+ years?]
- Do we actually keep those promises?
- Who thinks we should be keeping these promises that various people didn't feel were needed?
- What promises can we make that make sense and that after ~8 years we feel we can reasonably keep?
- Who do we need to make these promises to?
- Do not do disruptive upgrades. Try to backport security fixes or do upgrades which do not change API/ABI issues.
- Be prepared to support the same package for the life of an Enterprise Linux release.
- Never replace or conflict with packages in the base Enterprise Linux.
- They should never require manual updates or changes between updates.
- Follow Fedora rules for bundling, licensing, and similar things.
- Packages will never disappear. [They don't disappear from Fedora 12 even if it is archived.. ]
- Packages will work from EL-X.0 to EL-X.N. [EPEL will rebuild packages regularly to deal with any ABI items]
- Packages are built against all of an Enterprise Linux 'base' (EG whatever is in CentOS/Scientific Linux base).
- Most software which uses a database back end requires schema updates ranging from dump/reload to long running change processes.
- A lot of software rebases itself internally to the point that trying to backport a security fix usually requires a lot of coding skill in the package.
- The Enterprise Linux lifetime has increased from 5 years to 10 years since EPEL started. While people were interested in supporting a package for 3-4 years.. doing so for 10 years is too much for a volunteer position.
- The Enterprise Linux is not the same as it was in EL-3/4/5 where software versions were rarely 'rebased' to a newer release. Instead software would be recoded to work in the older software as much as possible. Currently in EL-7, the desktop and other parts of the OS were greatly updated between 7.1 and 7.2 with the idea that this will be the norm for all releases in order to keep the product relevant to the majority of users.
What to Do?
- Ignore and do nothing. I don't like the status-quo but I think it needs to be listed as something that can happen.
- Try to keep the original charter and be a lot more picky about what is in EPEL so that we can meet those promises.
- Figure out what we can do, and go to the appropriate Fedora body to recharter ourselves to meet those more reasonable goals.
What would be in my charter
- EPEL is run by the EPEL Steering Committee. They act as sub-equivalents to the Fedora Extras Steering Committee, Fedora Packaging Committee and Fedora Release Engineering.
- Packages in EPEL will never replace or conflict with packages in the base Enterprise Linux.
- Packages in EPEL will follow Fedora rules for bundling, licensing, and similar things. Exceptions to this will exist and will be documented in appropriate place.
- EPEL release engineering can set up systems to rebase packages in regular intervals. [There are multiple ways of doing this that I will try to outline in other proposals this week.]
- The only promise of a lifetime of a package is between dot releases of the Enterprise Linux. Maintainers should make an honest effort to support a package for the "life" of a sub-release (6.8->6.9) but no longer.
- Packages in a dot release will not disappear during that time. There is no promise after that time. [If EPSco approves of a method that packages are regularly archived, then users can use that as a simpler method to get old packages.]
- EPEL only supports the current dot release. If a package in EL-6.now works on 6.0.z that is great. If it doesn't, it is up to the user (and not the maintainer or EPEL) to deal with it. [Again if an archive method is setup, then those older versions would just be in something like /pub/archives/epel/epel-6.8/ or some similar setup]