On Wed, 23 May 2012 17:50:00 -0400 Bryan J Smith <[email protected]> wrote:
Hey Bryan, I wanted to answer some of your points, but this week has been very hectic. ;( ...snip... > Enterprises who are customers of Red Hat run with all sorts of > software, including IHV, ISV, and even custom or custom-rolled. The > value of Extra Packages of Enterprise Linux (EPEL) is that they sport > the Fedora guidelines and related advantages. It also leads a number > of Red Hat customers to the Fedora project as maintainers too. Absolutely. Also, it allows folks to share support costs with other interested parties. ...snip... > But it's more than that, as you and others have identified. What > versions will go in? > > Does EPEL match Red Hat Enterprise Linux layered products? Well, that would depend on how the overlap is handled no? > Or does EPEL stay more leading edge with Fedora as possible? No. We have always agreed that EPEL was for enterprise use and rapid incompatible upgrades don't work with that. Fedora also has the advantge of releases every 6 months, so they can ask people to revisit incompatible upgrades when they make that jump. RHEL upgrades much less frequently, so we can't even use that very often to jump to a new incompatible version. > Or does EPEL just avoid both, and ship what only complements and does > not conflict with what is in Red Hat Enterprise Linux layered > products, as the latter can can be built from source RPMs by > downstream? I think the thing people are finding difficult about this is "all layered products", when many of them seem very niche/special purpose or not very well known. > And how does Fedora solve more leading edge desires in that case? Well, Fedora doesn't need to worry about RHEL, but in general incompatible upgrades happen at release boundries, which is every 6 months. So, a new thing comes up, you have to wait at most 6 months (but less if you use rawhide or a branched version of the next release). > Again, what is Extra Packages for Enterprise Linux? I guess that's > what I'm asking. "Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL),CentOS and Scientific Linux (SL)." ? ...snip... > Imagine a real-world enterprise with 5,000 systems. They have a RHN > Satellite server or some other provisioning, deployment, management, > etc... solution. They have various fractions of those systems using > various, layered entitlements, in the 100s here for something, 10s for > another, and probably the 1s for a select few (Directory, Satellite, > etc... come to mind). > > How do I advise a customer regarding EPEL in this situation? I would say: On machines you need packages from EPEL: * If they are general purpose machines that need a number of epel packages and don't have layered products just enable the epel repo/channel/whatever. * If they are specialized machines that do have layered products/channels, don't enable EPEL. If you need EPEL packages, include them specifically with 'includepkgs' (or whatever method). Perhaps it would help to know cases where machines have specific layered products enabled, but need a bunch of epel packages? I mean if you have a cloud node, what EPEL packages would be needed there? Wouldn't you just enable EPEL on the virtual machines _running_ on the cloud ? > Now factor in the the community advocates in the commercial entity. > They have been recommending they turn one of their useful, management > packages into a Fedora project with a maintainer, telling management > it will be built for RHEL in EPEL and they can deploy it to any and > all systems. They want to share it with other enterprises, via the > Fedora Project, so everyone can benefit. > > That's my world. I'm not trying to tell anyone what to do. But > that's just my world. It exists. It's real. I don't doubt it. Imput from your world is valuable to the discussion. ;) kevin
signature.asc
Description: PGP signature
_______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
