Thoughts from last meeting

[inode0]

On Tue, May 29, 2012 at 1:30 PM, Kevin Fenzi <kevin at scrye.com> wrote:
> On Tue, 29 May 2012 09:31:11 -0500
> inode0 <inode0 at gmail.com> wrote:
>
> ...snip...
>
>> 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 fasttrack and
> 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. :)

John