Thoughts from last meeting

[seth vidal]

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).
> 
> 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.

my 2cents. I speak only for me not for my employer.

-sv