On Tue, May 29, 2012 at 1:30 PM, Kevin Fenzi <[email protected]> wrote: > On Tue, 29 May 2012 09:31:11 -0500 > inode0 <[email protected]> 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 _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
