Thoughts from last meeting

[Jon Stanley]

On Sat, May 26, 2012 at 12:37 PM, Bryan J Smith <b.j.smith at ieee.org> wrote:

> Which were always part of the "AS"/"Advanced Platform" entitlements,
> and rebuilt by most "EL Rebuilds," from virtually day 1.  And these
> have not been allowed under the past EPEL guidelines from day 1 as
> well, unless I am mistaken.

Perhaps for RHEL5, for RHEL6 they are sold and priced as separate
entitlements. Which brings up an interesting point, perhaps we should
treat EPEL5 and EPEL6 differently here, but have one unifying policy -
anything that you can get as a single line-item with the operating
system without extra add-on entitlements (i.e. for RHEL5, that would
be AP) is not to be included. If Red Hat decides to change the model
with RHEL7 or future, then that gives us flexibility without coming
back to this discussion at that time.

> So you would suggest EPEL take over this role, and the EL Rebuilds
> drop it as well?

Not rebuilding the exact SRPM's provided by Red Hat in the layered
products, no. However, if someone (who would most likely be the
engineering owner of that prodcut at Red Hat, let's face it) wants to
put their upstream bits into EPEL, I don't think that there should be
policy that stops them from doing that.

> Then why isn't that left to "EL Rebuilds" instead of Red Hat's
> sponsored Fedora Project when it comes to Enterprise Linux bits?

Like I said above, I think that EPEL should *not* just rebuild the
SRPM's that are shipped as part of RHEL layered prodcuts, that's not
the purpose of EPEL.

> Also, what do you believe this does to Red Hat customers who use EPEL?
>  Or are you under the believe Red Hat customers should not, which has
> been suggested prior?  Who does EPEL serve?

As a large Red Hat customer, I use EPEL - i.e. in pulling packages
from it internally and cherry-picking those that I want. If you just
want to enable the EPEL repo and are a RHEL customer, you should
probably use something like yum-priorities to make sure that we don't
override stuff in base RHEL+your entitled channels.
>
> Does Fedora's EPEL serve as the unified rebuild tree from Red Hat's
> SRPMS?  Or where is the line drawn?

Absolutely not. In fact, I would say that any packages that are
submitted to EPEL must NOT be simple rebuilds of SRPMS, and unique
NEVRA is a requirement. I would be mighty ticked if identical NEVRA
packages to what's shipped in layered products, all of which I
subscribe to, started showing up in EPEL, in fact. This is mostly
technical on my side, my storage mechanism works based on uniqueness
of NEVRA.

> And what if Red Hat does?  Do you accept such?  And who from Red Hat?
> And how does that work?

If Red Hat does what? In reality, I would think such a request would
come from Spot, who I always defer to in matters like this. The
request would be something like "stop shipping package XYZ, please"
and we would then do that.