Keep or remove GlusterFS from EPEL-6?

[Stephen John Smoogen]

On 16 May 2012 07:53, Bryan J Smith <b.j.smith at ieee.org> wrote:
> Niels de Vos wrote:
>> They are not under the "os" directory where most packages live:
>> ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/
>> It may not be a problem for binary derivatives of RHEL if they don't provide glusterfs packages.
>> But this may be a problem for people who use the Red Hat Storage bits.
>
> Far be it from me to interpret policy, so I'll just point how this
> comment nails the reality, and let others with the project decide.
>
> I.e., ask yourself ...
> Is the Fedora Project's EPEL just for community "EL Rebuilds" and derivatives?
> Or is EPEL for all, including the customers of the Fedora Project's
> sponsor, Red Hat?
>
> Alan Pevec wrote:
>> Why do they need to have EPEL repo enabled? Doesn't that make them unsupported?
>
> Again, here's the reality, and I'll let others with the project decide ...
>
> Yes, major Red Hat accounts tap EPEL, often bringing in the the EPEL
> YUM repository into their RHN Satellite Server.  It saves them having
> to build all sorts of upstream community solutions.  And yes, of
> course, these components in EPEL are _unsupported_.  But they remove
> not just a lot of the overhead of customers building-their-own, but
> the policies and other advantages of the Fedora Project itself can be
> leveraged.
>
> Leaving them in EPEL means that Red Hat customers now must clone and
> segment out the conflicting bits.  Although many accounts end up
> cloning channels into "internal releases" so the test EPEL components,
> it's still going to add to their workload.
>
> And with that all said, as I understand it, one of the reason for the
> EPEL guidelines were so Red Hat customers would not have conflicting
> components in EPEL that are also available from RHN.  Two, conflicting
> sets of packages on the same server, that is really, really
> _unsupported_, and causes headaches for Red Hat services and support.
> I.e., sometimes it takes a bit before this "root cause" is discovered
> (first hand experience speaking here).  ;)
>
> Which brings me to the final point, which is non-technical ...
>
> Marginalizing Red Hat customers, ones who fund a lot of what Red Hat
> does upstream (and downstream as well), is not probably the best move
> for the longevity of the Fedora Project, or "EL Rebuilds" who rely on
> Red Hat's continued funding.  This should be obvious to many here, but
> I understand there might be some community members here who may not
> see this immediately (hence why I'm pointing it out).


1) We decided about a year ago that if its not a SRPM in the RHEL OS
directory we would not count it as something we could not build
against. This was because we would have needed to remove puppet and
several other tools that various RHEL layered products included at old
releases that we had gone past in version by the time the product was
released.

2) Using any add on repository comes at a price. EPEL can do as much
as it can to lower that price, but at a certain point there are going
to be issues. In such cases I would say that a user has to realize
that certain packages are going to need manual intervention one way or
another. Or they can come up with a way to manage this better. EPEL is
a volunteer effort done in spare time of both Red Hat and non-Red Hat
employees. Our price for using our product is that people step up to
fix things when they are broken.



-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd