Stephen John Smoogen <[email protected]> wrote: > Well of course it is arbitrary. Any definition we use is going to be > arbitrary because well there is no rock solid proof that says "this is > RHEL" and "this isn't RHEL".
Actually, the leaders have done their best to try to define it. Unfortunately, they are getting pulled in many directions. I haven't taken issue with some suggestions, but others are literally trying to break down what used to be RHEL AS/AP. That has stood for 10 years no less. With version 6, Red Hat offered to break out AS/AP into more "buy what you want," so someone who just needed simple HA didn't have to buy the 5-10x product entitlement. But now people are jumping on that to tear it all down. Why is that? I think several people admitted why, and how EPEL solves that for them rather than tapping CentOS directly. All I know is that it is a mess that reminded me of several enterprises that tried and stopped using CentOS Extras. They wanted extra packages they couldn't get from Red Hat. When EPEL came around, it solved it for them. Now we're back to the same issue. So how do we solve it for everyone? I don't know. The leaders really have their work cut out for them. One of the suggestions that might work adds a burden on them, splitting it into two repos. And even that won't address everything. > Expecting us to define that definition when it is clear that even > Red Hat has no rock solid definition is preposterous. Red Hat has _always_ had a rock solid definition of AS/AP. Even today, the version 6 entitlements map to AS/AP. There's no reason to end those, not after 10 years of lineage. But some want to. And some have stated their reasons. And I have pointed them out. Expectations have been set prior. But now they have changed, and are still changing. Conflicts will happen. Changes will occur. But changes to expectations should be mitigated. > So this is our arbitrary line in the sand. It is no better or worse > than if we drew it 2 feet to the left or 2 feet to the right. However > until the tide comes in and washes it away, this is the one we > are looking to use. But in the process, you have to realize who is being considered the least. We're far more worried about giving the least subsidizing Red Hat customers everything they need, instead of also considering how much that will conflict with Red Hat's biggest, subsidizing customers. As I said, that is self-defeating for the project. You have to recognize no one is important than anyone else. From there, you have to see what can and should be done. If there is an argument that EPEL will lose packages and maintainers and that's the sole focus, I think people forget the flip side of that. Not only is there no reason why packages and maintainers can't work on the packages in a similar effort, possibly a separate Fedora repo or an external one, but the best one of all. Sit back and work this through ... I mean, wouldn't it be nice if Red Hat could employ them so they could do the packages full time? Just remember that consideration as well. ;) -- Bryan J Smith - Professional, Technical Annoyance http://www.linkedin.com/in/bjsmith _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
