inode0 <[email protected]> wrote: > Who might be affected is certainly a wider a net than the "owner" of > the layered channel.
Indeed. Every single customer of Red Hat I've been at in any capacity realizes this. I've seen reachback by consultants and support to engineering, including the actual coders. I've seen numerous, "special cases" where Red Hat has been leveraged for non-Red Hat software, because they have the upstream mindshare. I cannot emphasize this enough. That alone causes many stakeholders, when either downtime and/or unexplained results, to realize the value of entitlements. Because in those cases, the entitlements are pennies on the dollar, especially against either "unpaid" or, worse yet, proprietary options that cost 10x more. That's where my concern is at, not the downstream community users (who help Red Hat in many ways) and the thin margins like in the ISP/web space, where "EL Rebuilds" are admittedly more popular (especially for those that operate in-the-red). > But at the same time inclusion of *any* package at all in EPEL can > cause problems for GSS. As I sorta hinted earlier, I do have to admit that it goes beyond just things in Fedora like EPEL. There will always be the reality of people who will try to utilize Red Hat's support for not merely what is called "unpaid" open source, but open source that Red Hat has not unit, integration and regression tested as a whole As much as it may bother some when people take advantage of Red Hat individuals and their goodwill to "share" in paid, subsidized aspects, there can be grave contractual issues when it's in an enterprise. Most of the time, it's overlooked. But when it's on behalf of paid, but proprietary IHV/ISV who is shipping, referring to or otherwise providing an "unpaid" open source they don't even support, I really hate to have to remind people that it's unfair to do that to Red Hat (let alone "throw them under the bus" when I see it). The better response would be for a customer to go back to the costly, proprietary IHV/ISV and ask them why some of their money is not funding Red Hat entitlements instead of ripping the "unpaid" open source from the community. So while I'm sure anything that can be done to avoid "accidental" support is appreciated, no guidelines can prevent intentional misuse of Red Hat's trust. To me, it's not much just users who are "caught in a bind," which happens, and I've never seen anyone in Red Hat just say "no" to such users. But far worse from my view, it's proprietary vendors who do it very, very intentionally, and leverage the users and the community to "walk through the open door" they already have with Red Hat, instead of doing it themselves and walking in with the customer. > For large, well-heeled, enterprises it doesn't matter what content > EPEL includes because those enterprises take full responsibility for > what content they allow into their enterprises. I doubt most EPEL > consumers actually function this way though, even though they might > very much like to. Actually, most do. EPEL gets special consideration as a Fedora Project, understood to be unsupported, but a better release avenue than "rolling your own." The key is for stakeholders and SMEs to put this in the proper context for other, both technical and non-technical, stakeholders. It's hardly alone in the software world, as even proprietary, commercial vendors have their unsupported tools and utilities, along with other communities. Sometimes that reality, and the folly of believing it doesn't exist, is fun to point to with fellow MCSEs and MCITPs. > If EPEL doesn't want to take this responsibility then it is just another 3rd > party > repository and it might as well drop all restrictions based on conflicts with > RHEL > packages and leave sorting out the mess to the people using EPEL. I don't know if that is correct, but I do share that feeling. If EPEL is not helping enterprises mitigate much of their release model load, then it's just like tapping CentOS Extras, DAG, RPMForge and others. These are all good projects, no one is arguing that they are not, very helpful. I use their SPEC files myself, when required, and then I take maintainership, or document how to for others. But EPEL, at least in my experience, used to bring certain benefits, ones that mitigated the workload in the release life cycle. As always ... ;) -- Bryan J Smith - Professional, Technical Annoyance _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
