On Sat, 26 May 2012 12:24:14 -0400 Jon Stanley <[email protected]> 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 _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
