Thoughts from last meeting

[inode0]

On Tue, May 29, 2012 at 8:40 AM, seth vidal <skvidal at fedoraproject.org> wrote:
> On Sat, 26 May 2012 12:24:14 -0400
> Jon Stanley <jonstanley at gmail.com> wrote:
>> I agree with the sentiment, but it can help that even without
>> explicitly avoiding every single bit of package overlap.Do I think
>> that EPEL should ship a new kernel, coreutils, etc? Of course not. But
>> I don't think that EPEL should be categorically prohibited from
>> shipping something that overlaps with something else that is not RHEL
>> that Red Hat sells. I consider the layered entitlements (including
>> cluster and lb) to *not* be a part of RHEL - they are part of a
>> different product, sold and priced differently (the fact that you have
>> to have the base product in order to buy the layered ones makes no
>> difference either - I have to have a car, or else buying floormats
>> doesn't make any sense).

The notion of layered products in my mind got cloudy with the
introduction of the Red Hat Enterprise LInux Add-On category. While I
don't see layered products like those dealing with identity management
(certificate system, directory server) as being part of RHEL it is
hard for me to see the newer RHEL Add-Ons like Load Balancer as being
not part of RHEL. They seem to be the result of customers wanting a
lower cost basic version of RHEL that doesn't include all the bells
and whistles while allowing RHEL users with different needs to include
those bells and whistles from a menu of available parts of RHEL not
included in the lowest cost version. To me it is just like the old AS
vs. ES distinction but offered through a menu of add-ons rather than
through different versions of RHEL. This is marketing more than
anything else.

>> So to put it in concrete terms, I advocate that EPEL does not ship
>> anything that is in -server and -server-optional. Anything else is
>> fair game, unless explicitly asked by Red Hat to remove the bits.
>>
>
>
> I have been lurking along for a while here but I would like to put in
> my 2cents.
>
> I think Jon's proposal above:
>
>   inclusive of what epel's default limits are, disallowing of exact
>   rebuilds of any srpm from any channel and allowing for notification
>   from red hat through a specific and established source (his example
>   of spot is a good one but we don't need to necessarily throw spot
>   under the bus, other folks could be the epel-go-between too)
>
> is a good proposal. I think it is consistent, easy to understand and to
> explain and will help epel thrive.

This is certainly easy to understand and my only concern is from the
perspective of the EPEL consumer. If the Load Balancer Add-On were
provided by EPEL and I jumped on that only to have the epel-go-between
object 6 months later and have it pulled out from under me I would be
an unhappy camper. It is OK to say that is my tough luck, but in cases
like this I'd feel more confident using EPEL if the epel-go-between
said it was OK to include Load Balancer Add-On before it was included
rather than coming along later to say it isn't OK and yanking it.

John