Kaleb S Keithley wrote: > I don't see that as an issue. We're selling RHS/RHSSA to people to build > server appliances.
That's just one certified/partner initiative as I understand it. It's storage software. I'm not going to say anything else here on that matter. But if we're discussing how to proactively handle things in EPEL, I would not (as the Fedora Project, other viewpoints may vary) try to state what Red Hat may or may not do, especially looking to the future. David Egts wrote: > Somewhat related... > How do we plan to have a customer use GlusterFS as a native mount from > a RHEL system? We don't want them to inadvertently use our .com bits for the > server and the EPEL bits for the native client, and we don't want the native > clients > to consume a Red Hat Storage entitlement to get the bits from that channel, > correct? Do we plan to put the .com GlusterFS native client bits in the > mainline > RHEL channel? Right now, the RHSSA docs say that you're supposed to go to > gluster.com to get them. > http://docs.redhat.com/docs/en-US/Red_Hat_Storage_Software_Appliance/3.2/html-single/User_Guide/index.html#id3900239 > That doesn't sound right to me from a supportability standpoint. GSS doesn't > want > to tell people to use community bits and instead be able to yum install them > from a > cryptographically signed and authenticated redhat.com source. Kaleb S Keithley wrote: > Customers will have many different clients and they are free to get > bits to use from a variety of sources: 1) Fedora YUM repos, including > possibly EPEL, 2) gluster.org download site, 3) build from source. I have David's view here. However ... > I don't know, per se, how Red Hat Storage entitlements work, nor am I > sure it's important for the sake of this discussion wrt where they > get the bits for their clients. I agree that is more a discussion for Red Hat, when it comes to client and related support entitlements. However, the greater issue for the Fedora Project's EPEL SIG, which does affect Red Hat customers (which I've tried to maintain in all of my responses is) ... "How do ensure Red Hat customers with entitlements are not using or relying on EPEL components?" Remember ... community = { Fedora = { EPEL, Fedora, etc..}, community EL Rebuilds, 3rd party repos, etc... } EPEL is not the end-all, be-all. As much as we want everything to solve the issues for everyone, that's not going to happen. I can only offer how EPEL _has_ been sold inside of major enterprises and Red Hat accounts, to make it on the list of approved software for release deployment. In virtually all cases, there are still other release procedures, and it is not directly tapped and installed. But continued consideration of EPEL is going to related to reducing load on the enterprise release teams. I can completely understand some Red Hat customers are going to want the more leading-edge releases of some Red Hat entitlement products. I see many are still wrestling with renaming packages. Then there are issues of dependencies not in RHEL, but in an add-on entitlement, having packages that are different versions than in Fedora and, subsequently, EPEL. There are a lot of issues. At some point, maybe package renaming is not enough. Which brings me to ... Mike Snitzer wrote: > That seems amazingly odd. Why wouldn't we want RHEL to have the gluster > client? At many points in the RHEL product, Red Hat has taken a package or support in an add-on entitlement, and moved it into base RHEL. But even when Red Hat does that, it's not guaranteed not to (in fact, it's very likely) conflict with a newer, more leading edge version in Fedora and, subsequently, EPEL. So maybe what we're talking here is not really EPEL at all, but something that is designed to preserve versions in RHEL by not introducing newer ones in EPEL, or different package names in EPEL or RHEL. I've said it privately, but I'll now say it publicly ... Maybe we're talking about something that offers "Emerging Technologies for Enterprise Linux" (ETEL) in the greater Fedora Project. Maybe we're talking about sticking to what EPEL was designed to be, but building out something like an "ETEL." I think that work far better in the interests of everyone ... Red Hat customers with production deployments (EPEL), Red Hat customers who are early adopters of new technologies or new revisions (more ETEL, where FastTrack and other options aren't the avenue), as well as "EL Rebuilds" (who can rebuild production Red Hat add-on software, but also redirect users to ETEL for more leading-edge), and other community efforts, as well as Fedora itself. ETEL would have different guidelines than EPEL, including maintainers possibly needing to drop packages due to rebasing in RHEL or infeasibility of RHEL support due to newer dependencies in newer, leading edge releases (that RHEL doesn't have). Just an idea. I think we're missing the greater point here that we're talking EPEL specifically, not community, not greater Fedora Project, which has the ability and will (or should) to change to accommodate as many people as possible with its guidelines and, in this case, a plausible, new option. -- Bryan J Smith - Professional, Technical Annoyance http://www.linkedin.com/in/bjsmith _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
