inode0 <ino...@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 _______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
