EPEL * Extra packages for enterprise linux * Lots of name recognition now * Formed as rhel5 was being released people needed more packages. at the time there were a ton of addon repos. None of the m were compatible with each other necessarily. All the other repos, dag, freshrpms, etc overrode the base os in some places. Decided for EPEL, overriding RHEL was something we wouldn't do. Started with RHEL3,4 and soon after release we had 5. RHEL was supported 5-7years and we figured we could support EPEL packages for the same length of time. Early controversy - repotags (shortened name that can be in the packages. [graph of Fedora machines measured by unique ips that hit mirrormanager vs EPEL machines] [graph shows steady growth in EPEL. Larger initial Fedora machines that rose and then plateaued] [graph shows a noticable dip every weekend. Can also see the dip in Fedora numbers for the Incident.] [graph is probably conservative in numbers as many enterprises Second graph: [Graph shows combined growth same as last graph.] [Graph shows EPEL5 that has risen but plateaued about the time EPEL6 came out.] [graph shows that EPEL6 has been growing and has surpassed the EPEL5 plateau.] Where are we now: We support 3 arches. RHEL4: 1258 srpms. EOL RHEL5: 3651 srpms RHEL6: 5449 srpms RHEL7: 3100 srpms and growing fastest For CENTOS7: the epel repofile will be shipped directly with centos for the first time. Current Problems: * 10+ year support for RHEL now. Hard for EPEL packagers to commit to doing the same. * We have requests for both newer and older conflicting packages. - Currently policy is not to have unpleasant surprises regarding compatibility. - puppet2.x vs puppet3.x * Some people need major changes to build new software * Some people need no changes in order to keep existing software running * Developer burnout: People come in and after a few years, they are burnt out because they can't upgrade the things that they want due to the compatibility policies. Where are we going? Pain Points: * Inability to yum downgrade because only include one old package in the updates tree * Harder for EPEL than Fedora because EPEL users have more need to rollback if an incompatibility creeps in and because EPEL users may schedule their releases * Not every part of package repo is suitable for inclusion in anaconda because we may not have dep closure in the subset of the repo. * Which RHEL point release can also make a difference because the base RHEL sometimes upgrades incompatibly and we don't keep a separate build for both point releases. * Can take a long time to push packages through bodhi. Can take 7 days to push a CVE through bodhi. (global EPEL and Fedora problem) * Not all maintainers interpret "Don't break compatibility" in the same way. * Many guidelines are verbal, not formal. * Some maintainers are mainly Fedora maintainers and don't know what people are using it for in EPEL. They respond to requests to install or update a package out of a willingness to help but don't know what users need. * No guideline enforcement. * Takes a while for new EPEL releases to be brought out once a new RHEL release is made (because CentOS hasn't released yet). * Traditionally, we wait because contributors may not have RHEL entitilements so they need to have CentOS to test. * Need entitlements for contributors to run RHEL (Easiest: Use RHEL, SciLinux, Fermi Linux). * Packages get added to one of the RH base repositories and then we have to pull them from the EPEL repositories. * Some people have extra layered products from RH and do not want us to conflict with those. Other people do not have the layered products and therefore want to be able to get those packages from EPEL. * Overlap between EPEL and CentOS Extras. Ideas to deal with Pain * Get RHEL licenses for contributors. There is a process but it takes a long while because of the tax problems for giving it to people. Current procedure is that we get requests, we give the names to a person inside of RH and then they eventually get back to us with licenses. * Let's create EPIC: separate repo. 3 year lifespan instead of 10 year, rhel life cycle. * Debian Volatile repository and also Debian Backports. These repos contain newer versions of packages, even for Debian Stable. Good for packages which change all the time. * Debian also has protection mechanism that says no major or no major.minor version updates in apt (their yum equivalent). * Red Hat already releases different lifecycle repositories (layered products). Why not replicate what they do. * What about implementing EPEL as a set of projects like Fedora Playground? * Would change the guarantees and expectations of EPEL *quite* a bit. * Maybe as the way to implement EPIC rather than EPEL. * Policy change that allows for regular major changes in EPEL. * Can't update at any times. * Can make incompatible changes on the next point release of RHEL->CentOS. * Example: When RHEL7.1 comes out we have a 30 day window to get packages updated and new packages in that make incompatible changes. * Archive 7.0. The toplevel 7 tree is a symlink to whatever point release is latest. * Formalize the governance of EPEL. * Written policies of some sort for decision making * Elections? * Problems to solve: * Don't want to just listen to the people who are loudest * Don't wnat to just listen to the people who have been around the longest * Do we want automated testing of EPEL? yes. get it working on whatever subset you can and we'll go on from there. * Move to CentOS as build system? Gives us additional arches. * Could we do an ISV program like quaid does?