Thoughts from last meeting

[Bryan J Smith]

Kevin Fenzi wrote:
> 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'm sure some would feel that goes too far "the other way."

> 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?

I've commented on Fasttrack before when I mentioned ETEL originally.
But that's a whole other can'o worms, especially when it comes to the
conflicting version debates.  In general, I would not even attempt to
accommodate systems that are subscribed to Fasttrack in EPEL (among
other things).

Now as far as Extended Update Support (EUS aka Z-stream), understand
most layered entitlements are not under EUS.  So EUS is almost a
non-worry for EPEL.  Yes, many enterprises do run completely on EUS,
with only a handful of exceptions.  But in most cases, the problem
with EUS isn't one of conflict, but dependencies.

E.g., an EPEL package that has a dependency on something that, say,
didn't ship until RHEL5.8, would not be resolvable on a system
subscribed to RHEL 5.6 EUS.  Again, not a conflict issue, so nothing
to worry about.

If anything, EUS is "better" for EPEL.  Things either resolve, or they
have missing dependencies.  I can deal with missing dependencies far
easier than conflicts.  ;)


Kevin Fenzi wrote:
> Just to note here, any addition of additonal repos is not going to be
> "oh, lets toss that out and it's all done".

Again, my comment was in response to someone saying >>2 would be
required, among other things, to implement the desired detail.  I
don't think anyone was suggesting that one would need to create a repo
for every Red Hat layered product.  That would be way, way too fluid.

My only comment was that if the project is going to yank packages, I'm
not against them finding a home in another repository.  The "two"
comment then comes down to having one that does not conflict, and
another that can.  I'm not the only one to suggest such, and I
recognize it's been considered before.

But >>2 was nothing anyone suggested.  Don't know why someone went there.


--
Bryan J Smith - Professional, Technical Annoyance
http://www.linkedin.com/in/bjsmith