Thoughts from last meeting

[Bryan J Smith]

inode0 <inode0 at gmail.com> 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