On Sat, May 26, 2012 at 8:46 AM, Bryan J Smith <b.j.smith(a)ieee.org> wrote:
inode0 <inode0(a)gmail.com> wrote:
> 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.
None of this is a problem that EPEL can solve. We accept packages that
meet various criteria that are more restrictive than other 3rd party
repositories. If an EPEL consumer, whether a Red Hat customer or not,
wants something in an upstream repo and EPEL won't provide it for
whatever reason there are others that will provide it. So Red Hat will
have whatever support problems result from customers using the package
either way.
> 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.
Are you seriously saying that most EPEL consumers behave in their IT
shops like large financial institutions? I'd bet not 1 in 10 do. I'd
probably bet not 1 in 100 do. EPEL is the 1st choice of many small IT
shops because they make the decision that they can trust EPEL to vet
packages for them. They want to get a package they need by enabling a
repo, installing it, and going back to figuring out why backups are
failing. :)
John