Thoughts from last meeting

[inode0]

On Sat, May 26, 2012 at 1:53 AM, Jon Stanley <jonstanley at gmail.com> wrote:
> On Fri, May 25, 2012 at 6:05 PM, Kevin Fenzi <kevin at scrye.com> wrote:
>
>> If layered product folks start getting a flood of "I'm using version
>> $foo of your product" and thats the version shipped in RHEL instead, we
>> might drop this from EPEL to avoid causing undue support burden on
>> them? Then again, another layered product might say "well, thats not
>> what we ship, reinstall with $foo before we support you" Or another one
>> might say "we think it's great that EPEL ships this so we can get more
>> people testing it and providing feedback".
>
> In reality "layered product folks" is GSS. They get *all* support
> inquires, no matter how large the customer. If they have a TAM, that
> TAM is in the GSS org structure. So we can safely ignore the product
> management side of this (who could probably be considered the "owners"
> of the layered product channels).

Who might be affected is certainly a wider a net than the "owner" of
the layered channel. But at the same time inclusion of *any* package
at all in EPEL can cause problems for GSS. I think this bit should be
dropped or replaced by something more generic stating the willingness
of the EPEL community to work with Red Hat to resolve any issues that
EPEL causes that adversely affect Red Hat operations, but short of a
guarantee that Red Hat can decide what is or isn't accepted by EPEL.

> In my world, we carefully screen every repo that we produce (via an
> internal repo building mechanism) for things that do not have the RPM
> signatures that we expect (which is the RHEL prod signature, plus a
> manually maintained whitelist of unsigned, EPEL, IHV, etc packages).
> Anything that snuck in from EPEL (or a RHEL beta, or whatever source
> it might be from, including unsigned) would be thus caught unless it
> was on the whitelist. I would posit that anyone who cares about the
> provenance of their packages, and knowingly consumes packages from
> alternative repos (EPEL being an example of such) does the same. If
> they don't, then the onus is on them to do something about it - not on
> EPEL to prevent them from shooting themselves in the foot.

For large, well-heeled, enterprises it doesn't matter what content
EPEL includes because those enterprises take full responsibility for
what content they allow into their enterprises. I doubt most EPEL
consumers actually function this way though, even though they might
very much like to. If EPEL doesn't want to take this responsibility
then it is just another 3rd party repository and it might as well drop
all restrictions based on conflicts with RHEL packages and leave
sorting out the mess to the people using EPEL.

John