On Tue, May 29, 2012 at 8:40 AM, seth vidal <skvidal(a)fedoraproject.org> wrote:
On Sat, 26 May 2012 12:24:14 -0400
Jon Stanley <jonstanley(a)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