Keep or remove GlusterFS from EPEL-6?

[Bryan J Smith]

Stephen John Smoogen wrote:
> Well here is the issue. We have been delivering layered products for a
> long time (probably since the beginning) mainly because various groups
> did not want to do an Emerging Technologies for Enterprise Linux.

I thought layered products were based on sustaining engineering and
related support costs?

Or by "we" you mean Fedora EPEL pulls in Enterprise Linux source code
and rebuilds, instead of pulling from more leading-edge Fedora
versions?

And if it is the latter, is that always true?  How often do we go
leading edge Fedora version in EPEL, when a Red Hat layered product is
an older version?

> Hey they can use whatever they want.  It is up to entities I have no
> say or control in whether it will be supported by either consultants
> or Red Hat support.

Enterprises who are customers of Red Hat run with all sorts of
software, including IHV, ISV, and even custom or custom-rolled.  The
value of Extra Packages of Enterprise Linux (EPEL) is that they sport
the Fedora guidelines and related advantages.  It also leads a number
of Red Hat customers to the Fedora project as maintainers too.

Red Hat, IHVs, ISVs and the like are not going to be able to provide
and support everything.  It's better if customers and users have a
concentrated point for shared maintainership than for each to do their
own.  Again, I will not interpret what EPEL is, but if it is
conflicting with what Red Hat ships, then it loses value for them.

I have a further example and point on this, but I'll leave it for your
last statement.

> The issue is that if EPEL pulls out core packages every time Red Hat
> decides to offer a sub-channel of supported, then there is no need for
> EPEL since it will get gutted regularly. At this point we are looking
> at 1/3->1/2 of EPEL having to be removed because packages require or
> buildrequire items that are included in layered products that would no
> longer be available to build against.

But it's more than that, as you and others have identified.  What
versions will go in?

Does EPEL match Red Hat Enterprise Linux layered products?
Or does EPEL stay more leading edge with Fedora as possible?

Or does EPEL just avoid both, and ship what only complements and does
not conflict with what is in Red Hat Enterprise Linux layered
products, as the latter can can be built from source RPMs by
downstream?
And how does Fedora solve more leading edge desires in that case?

Again, what is Extra Packages for Enterprise Linux?  I guess that's
what I'm asking.

> Which leads me to my first statement, that the usability of EPEL to a layered
> user is much less than a base OS user.

I really should step back and point out a bigger detail ... and I hope
you'll see my greater point.

We're not talking a few systems or a single site SMB installation.
We're not talking about enterprises directly subscribing their systems
to the EPEL repo.

Imagine a real-world enterprise with 5,000 systems.  They have a RHN
Satellite server or some other provisioning, deployment, management,
etc... solution.  They have various fractions of those systems using
various, layered entitlements, in the 100s here for something, 10s for
another, and probably the 1s for a select few (Directory, Satellite,
etc... come to mind).

How do I advise a customer regarding EPEL in this situation?

Now factor in the the community advocates in the commercial entity.
They have been recommending they turn one of their useful, management
packages into a Fedora project with a maintainer, telling management
it will be built for RHEL in EPEL and they can deploy it to any and
all systems.  They want to share it with other enterprises, via the
Fedora Project, so everyone can benefit.

That's my world.  I'm not trying to tell anyone what to do.  But
that's just my world.  It exists.  It's real.

So I just need to know what EPEL is.  ;)

-- Bryan

P.S.  I've probably said everything at this point.  I will let others
debate and decide.  I just wanted all considerations interjected, and
I waited until I didn't see those considerations and details
interjected by others.