[gluster-internal] Keep or remove GlusterFS from EPEL-6?

[Kevin Fenzi]

On Thu, 17 May 2012 11:47:29 -0400
Bryan J Smith <b.j.smith at ieee.org> wrote:

...snip...

> However, the greater issue for the Fedora Project's EPEL SIG, which
> does affect Red Hat customers (which I've tried to maintain in all of
> my responses is) ...
> 
> "How do ensure Red Hat customers with entitlements are not using or
> relying on EPEL components?"

Indeed. This is a situation we sure want to avoid. 

...snip...

> At some point, maybe package renaming is not enough.  Which brings me
> to ...

Yeah, package renaming is going to add to confusion a lot of times, not
help it. ;( 

...snip...

> Maybe we're talking about something that offers "Emerging Technologies
> for Enterprise Linux" (ETEL) in the greater Fedora Project.  Maybe
> we're talking about sticking to what EPEL was designed to be, but
> building out something like an "ETEL."
> 
> I think that work far better in the interests of everyone ...

There has been discussion of this kind of thing in the past. Issues
have been: 

* What can be in this repo? We would need very clear guidelines. 
Would it be for shipping foobar2.0 when RHEL ships 1.0? 
Would it be ok to ship foobar 1.0 when RHEL ships 2.0?

* Resources. Would there be enough interest in such a repo to justify
  the rel-eng, mirroring, etc resources it would take up?

> Red Hat customers with production deployments (EPEL), Red Hat
> customers who are early adopters of new technologies or new revisions
> (more ETEL, where FastTrack and other options aren't the avenue), as
> well as "EL Rebuilds" (who can rebuild production Red Hat add-on
> software, but also redirect users to ETEL for more leading-edge), and
> other community efforts, as well as Fedora itself.  ETEL would have
> different guidelines than EPEL, including maintainers possibly needing
> to drop packages due to rebasing in RHEL or infeasibility of RHEL
> support due to newer dependencies in newer, leading edge releases
> (that RHEL doesn't have).

Right. 

> Just an idea.  I think we're missing the greater point here that we're
> talking EPEL specifically, not community, not greater Fedora Project,
> which has the ability and will (or should) to change to accommodate as
> many people as possible with its guidelines and, in this case, a
> plausible, new option.

yeah. 

I think we need more data to really move forward much more here, and
Smooge is looking at gathering the src.rpm data from 6/* repos, so we
can know at least whats affected here. (glusterfs is far from the only
thing)

Once we have that data, we can look at alternatives, discuss and see if
we can reach a consensus on how to move forward. 

One curious thing to me is that since we messed up dropping things when
the new channels appeared, how much pain has the overlap caused anyone?
Does anyone know of folks who had the EPEL gluster installed rather
than the RHS version or the like? I'm curous that we haven't heard much
about this for many months... 

Anyhow, I think we can look at data and come up with a plan, weather
that plan is another repo with new rules, removing things, deciding on
a channel by channel basis what we overlap with, etc. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20120517/7ac9ba4e/attachment.sig>