EPEL Notes from .next discussion.

[Dennis Gilmore]

On Tue, 12 Aug 2014 21:05:07 +0200
Stephen John Smoogen <smooge at 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