Thoughts from last meeting

[Jon Stanley]

On Sat, May 26, 2012 at 9:46 AM, Bryan J Smith <b.j.smith at ieee.org> wrote:

> 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.

Of course, you'd have to be living on some other planet to not
understand this. But mostly that's a highly technical discussion, with
understanding that things are either upstream heading into RHEL, and
extremely unsupported (at least via GSS). I can't count how many times
I've had Red Hat engineering ask me to try something on a Fedora box
and give feedback, etc. That's just the way it works.

> 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

I'm not sure what this has to do with EPEL - folks often use much more
than the stock RHEL bits. For example, pretend you had a web server
running Red Hat's httpd, but it loads a proprietary module to talk to
an app server. If that web server breaks, the first place people are
going to call is likely Red Hat. I wouldn't expect RHT to say "well,
you've got this module loaded over here. Your problem admittedly has
nothing to do with that, but we can't help you anyhow".

> 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.

Exactly. If something is in EPEL we hold it in higher regard than
"hey, look! I found this cool thing on the Internet!". Not saying that
we wouldn't take the cool thing found on the Internet, but it gets
subject to much more scrutiny than if it were packaged in 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.

I agree with the sentiment, but it can help that even without
explicitly avoiding every single bit of package overlap.Do I think
that EPEL should ship a new kernel, coreutils, etc? Of course not. But
I don't think that EPEL should be categorically prohibited from
shipping something that overlaps with something else that is not RHEL
that Red Hat sells. I consider the layered entitlements (including
cluster and lb) to *not* be a part of RHEL - they are part of a
different product, sold and priced differently (the fact that you have
to have the base product in order to buy the layered ones makes no
difference either - I have to have a car, or else buying floormats
doesn't make any sense).

So to put it in concrete terms, I advocate that EPEL does not ship
anything that is in -server and -server-optional. Anything else is
fair game, unless explicitly asked by Red Hat to remove the bits.