On Tue, May 29, 2012 at 1:30 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Tue, 29 May 2012 09:31:11 -0500
inode0 <inode0(a)gmail.com> wrote:
> 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.
So, you are suggesting an 'opt in' rather than 'opt out' ?
ie, if we hear nothing we shouldn't conflict, but if we specifically
hear from them 'ok, we don't mind, it doesn't cause us any issues' we
should only then allow conflicts from that channel/product?
I guess I would imagine it working more like a maintainer steps up and
says I would like to include package X which conflicts with
layered/add-on product Y. Any objection? Then the epel-go-between says
fine or no wait.
One other thing that comes in here... there's a bunch of
z-stream channels. Should any policy we draft address them as well?
fastrack only contains a subset of updates for the base channels
associated with them so I think it is safe to completely ignore them
from an EPEL policy perspective. z-stream seems redundant in a
different way and I would expect z-stream users to just use EPEL like
everyone else. If EPEL can't support two repositories then I'd look
the other way when z-steam support comes up. :)