On Tue, 12 Aug 2014 21:05:07 +0200 Stephen John Smoogen <smo...@gmail.com> wrote:
> At FLOCK this year, I did a short workshop on what was labeled > EPEL.Next. At that we went over a bit of what EPEL has done in the > past, what its current challenges are, and what could be its future. > Toshio Kuratomi was great in capturing what was said at the meeting > and > > 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. I think you mean 3 releases. we have 3 arches for epel5 and epel6 and 2 for epel7 > 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. I think i would like to see us add an epel-extras repo where things can change faster. Things like mediawiki, puppet, etc could go in extras. > 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 want 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? something to consider is moving epel to /opt/fedora/epel or somewhere like it, then dealing with overlap etc should be simpler, but it would take a massive change in packaging and could really only be done in epel8 Dennis _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel