On Thu, Feb 18, 2016 at 2:39 PM, Bryan J Smith <b.j.smith@ieee.org> wrote:
Stephen John Smoogen wrote:
> Sorry what I meant that it is built against all of RHEL not just a
> couple of channels. Again this isn't a promise we ever made, but one
> people assume we have made (and get surprised when they find out
> differently).

I can only imagine how difficult this gets for EPEL maintainers, even
the ones with the RHEL Developer Suite subscription.  There are just a
lot of add-ons and channels to track, even ones not in the RHEL Dev.

As I've mentioned in years prior, the only way to prevent this is for
the CentOS team to build everything, and that's a tall order, and only
getting to be a bigger and bigger task by the day.  So EPEL is really
one of those things that Red Hat customers pull down, but don't enable
... until something specifically is needed, and then it's checked for
conflicts, and only on a small subset of systems.

Non-Red Hat customers running CentOS usually have a much easier task
of enabling EPEL, although there can still be some issues.

> And this is where I made things worse by conflicting with channels
> versus "entire OS"

I don't think there is a perfect answer that satisfies all, and never
will be.  And definitely not 4-5 years into where EPEL is today, from
where the Red Hat product line went more and more vertical than it
ever was before.

It's one of those things that people have just accepted.  Although it
is good for maintainers to recognize that the EPEL build system is
going to -- gasp -- build against Red Hat packages, and not CentOS. ;)

> Probably but I would prefer to either have them one way or another :).
> I would prefer not to have the "where is my N?" during the decay days
> of EPEL-6 that we are seeing in EL-5 as packages get EOL'd that
> people expected to be there.

Maybe I'm throwing this out in ignorance ...

But maybe [Red Hat] Software Collections ([RH]SCL) offers a baseline
for a  "reasonable lifecycle" that should be a target?  I.e., 3 years.

E.g., any software that makes it into EPEL will have a "soft target"
of at least 3 years support?

RHSCL is a non-starter where I work (and I imagine at other locations). 2-3 years of support just isn't enough to make it a worthwhile investment. For example, we just barely started upgrading to EL 7 and it will be years until a sizable portion of our machines have moved to EL 7 (we still have quite a few EL 5 boxes).

For most packages, leaving the version that's there alone is probably a decent solution, but for packages where security fixes continue to happen and are important, then an "official" upgrade path would be good. Maybe something like:
1) Current maintainer identifies upgraded version and reason for update (hopefully limited to security fixes or something along those lines and not just "I want a newer version"),
2) Notifies intention on mailing list,
3) Feedback from community, and
4) Perform upgrade

Something like this could potentially get maintainers to step up that are willing to continue maintaining the current version. But in most cases, I'm guessing this wouldn't happen but would give an official process and expected timeline for user users.