Thoughts from last meeting

[Bryan J Smith]

inode0 <inode0 at gmail.com> wrote:
> I'm not sure it is that dire. Do we know if Red Hat cares about EPEL
> providing complete RHEL Add-Ons? If they don't then my concern is
> gone.
> I can imagine pulling in libraries needed as dependencies to be viewed
> as ok while completely replacing RHEL Add-Ons not being viewed as ok.
> There may be some middle ground even if EPEL doesn't provide RHEL
> Add-Ons.

If I may be so bold, I believe some (not yourself) are looking at this
the wrong way.  The way I have always looked at it, the Fedora Project
is really designed to help Red Hat, both upstream and downstream, as
much as the community.  In that regard, we should really get past this
"worry," and get to the bigger issue, even for Red Hat, as much as
downstream.

I think you're hitting on it well here, so let me expand on my view if
I may.  Many in the EPEL SIG have already identified a lot of
conflicts and issues, things that I feel Red Hat could benefit from.
In my experience, Red Hat can always use more input and assistance.  I
think has been obvious ever since Red Hat Linux 10 Beta became Fedora
Core 1 Test, at least to me.

So I honestly believe the answer lies in a more direct engagement with
Red Hat product and release management.  Most specifically, leverage
the EPEL community SMEs to identify:
1.  common support libraries and components which should be in RHEL
base channels
2.  resulting conflicts between support libraries and components in
RHEL layered channels
3.  package and other naming conventions to address possible needs for
multiple versions

All of these details work in favor of RHEL as much as the EPEL SIG
downstream.  Let's make that point clear with Red Hat, it's that
"extra set of broad eyes."  I am willing to assist any way I can,
since I'm heavily customer-facing and this continually affects large
Red Hat customers.  This is really a case where the Fedora Project can
and does holds extensive value-add, and it's clear Red Hat could use
some input at times.

BTW, this is in addition to my personal and continuing favorite (some
of you have heard me harp on this via other avenues) ...
- Facilitate easier access not just to RHEL entitlements for EPEL
maintainers, but layered entitlements too -- e.g., a "pool" that can
be assigned by Fedora Project leaders

My view has been the "gold standard" for development and builds in
EPEL should be RHEL+layered entitlements.  Red Hat only shoots itself
in-the-foot if it doesn't not make them readily available to EPEL
developers.  It also gets back valuable feedback, things that help Red
Hat avoid issues with its own customers.  It's win-win-win for Red
Hat-customer-community to do so, and that has been my long-standard,
long-held view.

As always, my views are my own only.


--
Bryan J Smith - Professional, Technical Annoyance