On Tue, May 29, 2012 at 8:40 AM, seth vidal <[email protected]> wrote: > 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).
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 _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
