On Thu, 17 May 2012 11:47:29 -0400
Bryan J Smith <b.j.smith(a)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