EPEL6 When to go out of Beta?

Chris Adams cmadams at hiwaay.net
Tue Nov 16 05:08:22 UTC 2010

Once upon a time, Jesse Keating <jkeating at redhat.com> said:
> I think part of the reason is that non-RHT customers have no binaries in
> which to test their builds upon.  Ballparking here, but I think not a
> small amount of EPEL packagers are CentOS (or other) users and not RHEL
> users.

I've probably come off sounding short/argumentative in this, and I want
to apologize for that.  I'm really just trying to figure out the reasons
behind the choices and decisions.

What does "released" mean for EPEL?  AFAIK it doesn't mean "100%
packages available".  There is a set of packages that are (or at least
are believed to be) ready now; why not release them now?  If someone is
waiting on CentOS to get their packages ready, that's okay; those
packages won't be in the EPEL 6 release tree until they are.

That's why I asked if there is some metric to use to decide when EPEL is
"ready".  If it is X% of packages, or certain "major" packages, that
should be documented somewhere, and then when that point is reach, EPEL
can be released.  I don't see any reason for just waiting an arbitrary
amount of time (what if nothing really changes in a month?).

EPEL doesn't have separate release and updates trees; there's just the
EPEL tree.  Packages are added as somebody picks them up, so I would say
just release what is considered ready now and let EPEL 6 grow over time
(just like previous EPEL versions have done).

> That said, I think it would be quite fair to grant each EPEL packager
> with a RHEL developer entitlement which could be used to test their
> builds upon.

That would be nice, although it would probably require some minimum
level of commitment (e.g. not people like me that only maintain a couple
of very minor packages, and otherwise just agitate in Bugzilla and on
mailing lists :-) ).

I still think some clear direction about which OS is the primary target
for EPEL (RHEL or CentOS) should be stated.  Since CentOS will always
lag RHEL (not through any failure of CentOS; it is just a fact), EPEL
can either target RHEL and update things when new RHEL updates come out
that require EPEL changes, or wait until CentOS gets the compatible
update in place.  You can't have it both ways, at least not for the same
packages, and I would think the policy should be the same for all of

CentOS also already has its own set of add-on repos (although not near
as large as EPEL) that have some overlap with EPEL.  My personal
preference (of course because I use RHEL) would be for EPEL to stay
current with RHEL, rather than wait for CentOS.

For example, in the situation where RHEL releases a backwards
incompatible security update that requires an updated EPEL package, but
the EPEL package is waiting for CentOS, a "yum update" will not load the
RHEL security update unless you first remove the old EPEL package,
blocking the update from RHEL users.

On the other hand, if the EPEL package is updated before CentOS gets the
security update, the CentOS users can use --skip-broken to just skip the
EPEL update they can't yet load, and RHEL users can load all their
updates.  Once CentOS gets the update, they'll get the EPEL update as
well.  I think that's a better situation.

Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

More information about the epel-devel-list mailing list