Overlap policy v20120615

Bryan J Smith b.j.smith at ieee.org
Fri Jun 15 19:58:43 UTC 2012

Jeff Sheltren <jeff at tag1consulting.com> wrote:
> I'd like to second this.  Keeping EPEL "working well" with CentOS is
> very important to me, and I know many others that only use EPEL with
> CentOS servers.

But you have to consider what select others are also suggesting ...

They believe instead of different EL Rebuilds taking the Red Hat
SRPMS, possibly deciding (possibly differently) what Red Hat SRPMS
they should rebuild and include in one or various repositories, they
believe the Fedora Project's Koji system and other Fedora-Red Hat
servers and their stewards should do it for them.

For the EL Rebuilds, this offers both ...
A)  Consistency between EL Rebuilds
B)  Reduced efforts by the EL Rebuilds

This includes several arguing to continue the breakdown of the channel
packages traditionally from the 10 year-old AS/AP add-on lineage
(which includes lb, rs and others), which has a 5-10x
support/sustaining cost for Red Hat (hence the related entitlement
offerings).  Again, these have been around for 10 years now, and not
the the new, additional add-ons where Red Hat has expanded its
offerings (such as the original Gluster/Red Hat Storage 2.0 debate).

Several have even commented how they like the idea of EPEL handling it
so they don't have to be tapping CentOS repositories.  So their point
becomes that customers either just purchase a basic Red Hat
entitlement, or just run an EL Rebuild, and get everything else from
EPEL.  That means EPEL is no longer designed for those customers who
fund Red Hat for additional add-ons and the related, additional
sustaining engineering costs (beyond the support aspects).

Ergo, they suggest EPEL move to both alienate Red Hat's best, GPL
development subsidizing customers, while solving consistency between
and reducing efforts by the various EL Rebuilds.  I cannot think of
something that is more self-defeating for the project than this.

Bryan J Smith - Professional, Technical Annoyance

More information about the epel-devel-list mailing list