Red Hat Launches New Package Repository for Enterprise Linux

[Rahul Sundaram]

Hi


It is a Fedora Project rather than a Red Hat specific effort but good to 
get the word out.

http://www.linuxelectrons.com/news/application/10941/red-hat-launches-new...

"Red Hat has launched a new package repository for enterprise-class 
Linux (EL) distributions derived from Fedora, such as Red Hat Enterprise 
Linux or CentOS, called EPEL. Extra Packages for Enterprise Linux (EPEL) 
is a community of package maintainers working from inside of Fedora"

Rahul

[Gain Paolo Mureddu]

Rahul Sundaram escribió:
>  Hi
>
>
>  It is a Fedora Project rather than a Red Hat specific effort but good 
>  to get the word out.
>
>
> http://www.linuxelectrons.com/news/application/10941/red-hat-launches-new...
>
>
>
>  "Red Hat has launched a new package repository for enterprise-class 
>  Linux (EL) distributions derived from Fedora, such as Red Hat 
>  Enterprise Linux or CentOS, called EPEL. Extra Packages for Enterprise 
>  Linux (EPEL) is a community of package maintainers working from inside 
>  of Fedora"
>
>  Rahul
>  
I was reading about this in the Announce ML and thought it was pretty 
cool, actually. This is *exactly* what Red Hat and CentOS were missing. 
Now they only have to issue an update batch where they also include as 
dependencies the required packages to configure these extra repositories 
in the deployed and supported distributions so users would have to do 
zero to very little configuration and start using these packages.

[Bryan Smith]

On Sun, 2007-07-29 at 17:16 -0500, Gian Paolo Mureddu wrote:
>  Now they only have to issue an update batch where they also include
> as 
>  dependencies the required packages to configure these extra repositories 
>  in the deployed and supported distributions so users would have to do 
>  zero to very little configuration and start using these packages. 
I've re-read this a couple of times and I'm still confused on what you
meant by an "update batch"?  And provided by whom?

Not looking to be critical at all, just wondering what is missing.  I'm
missing something in what you stated.  ;)


-- 
Bryan J. Smith         Professional, Technical Annoyance
mailto:[e-mail]   http://thebs413.blogspot.com
--------------------------------------------------------
        Fission Power:  An Inconvenient Solution

[Rahul Sundaram]

Bryan J. Smith wrote:
>  On Sun, 2007-07-29 at 17:16 -0500, Gian Paolo Mureddu wrote:
> > Now they only have to issue an update batch where they also include as 
> > dependencies the required packages to configure these extra repositories 
> > in the deployed and supported distributions so users would have to do 
> > zero to very little configuration and start using these packages.
>  
>  I've re-read this a couple of times and I'm still confused on what you
>  meant by an "update batch"?  And provided by whom?
>   
He wants Red Hat to include EPEL as a repository by default. By "update 
batch", he is referring to the sync updates like 5.1. This needs to be 
discussed with product management. I will let you know if and when there 
is a change.

Rahul

[Bryan Smith]

Sundaram, Rahul wrote:  
>  He wants Red Hat to include EPEL as a repository by default.
>  By "update batch", he is referring to the sync updates like 5.1.
>  This needs to be discussed with product management.
>  I will let you know if and when there  
is a change.

That's what I thought, but didn't want to assume.

Now even as an outsider, I don't see it happening.
EPEL throws many wrenches into SLAs and guarantees,
among many other things, which we can revisit from RHL days.

EPEL is great.
EPEL can and should be accommodated as best as possible.
But I don't see that going into the product itself,
other than maybe the Fedora signing key for security.

At least if I was a product manager at Red Hat,
that's just the line I would have to draw for SLA reasons.

--  
Bryan J Smith - mailto:[e-mail]  
http://thebs413.blogspot.com  
Sent via BlackBerry from T-Mobile  
    

-----Original Message-----
From: Rahul Sundaram <sundaram(a)fedoraproject.org&gt;

Date: Mon, 30 Jul 2007 13:36:30 
To:For discussions about marketing and expanding the Fedora user base
<fedora-marketing-list(a)redhat.com&gt;
Subject: Re: Red Hat Launches New Package Repository for Enterprise Linux


Bryan J. Smith wrote:
>  On Sun, 2007-07-29 at 17:16 -0500, Gian Paolo Mureddu wrote:
> > Now they only have to issue an update batch where they also include as 
> > dependencies the required packages to configure these extra repositories 
> > in the deployed and supported distributions so users would have to do 
> > zero to very little configuration and start using these packages.
>  
>  I've re-read this a couple of times and I'm still confused on what you
>  meant by an "update batch"?  And provided by whom?
>   
He wants Red Hat to include EPEL as a repository by default. By "update 
batch", he is referring to the sync updates like 5.1. This needs to be 
discussed with product management. I will let you know if and when there 
is a change.

Rahul

-- 
Fedora-marketing-list mailing list
Fedora-marketing-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-marketing-list

[Rahul Sundaram]

Bryan J Smith wrote:

>  
>  At least if I was a product manager at Red Hat,
>  that's just the line I would have to draw for SLA reasons.
>   
Good thing you aren't and Daniel Riek is ;-).Seriously though, the SLA 
might be a hurdle and this is one of the reasons I clarified it in the 
EPEL FAQ and some notes can be added within the repository file and 
other places too.

With the current state, EPEL has low visibility for RHEL users and we 
will be discussing that with product management folks.

Rahul

[Bryan Smith]

On Mon, 2007-07-30 at 18:05 +0530, Rahul Sundaram wrote:
>  Good thing you aren't and Daniel Riek is ;-). 
I'm just an outsider.  I have no idea what Red Hat's foci are.  I can
only make ignorant assumptions.  ;)

>  Seriously though, the SLA might be a hurdle and this is one of the
>  reasons I clarified it in the EPEL FAQ and some notes can be added
>  within the repository file and other places too. 
I know.  At the same time, if I was a Red Hat consultant on client site,
I wouldn't have to deal with the pressure of a SLA only to find out
there was breakage caused by EPEL.  I'm not saying EPEL will "break,"
but from the "anal power," there is that "risk."

I'm not trying to knock the outstanding work of the greater Fedora
Project, of which I have been signing praises for a long, long time --
ever since Red Hat Linux 10 Beta became Fedora [1] Test.  I'm a
well-known Red Hat apologist (and Novell apologist, etc... -- much to my
own demise at the hands of some very unethical people and illegal
actions).

>  With the current state, EPEL has low visibility for RHEL users and we
>
>  will be discussing that with product management folks. 
Understand.  Sorry if my commentary caused you any grief or issues on
your end.


-- 
Bryan J. Smith         Professional, Technical Annoyance
mailto:[e-mail]   http://thebs413.blogspot.com
--------------------------------------------------------
        Fission Power:  An Inconvenient Solution

[Gain Paolo Mureddu]

Rahul Sundaram escribió:
>  Bryan J. Smith wrote:
> > On Sun, 2007-07-29 at 17:16 -0500, Gian Paolo Mureddu wrote:
> >> Now they only have to issue an update batch where they also include 
> >> as dependencies the required packages to configure these extra 
> >> repositories in the deployed and supported distributions so users 
> >> would have to do zero to very little configuration and start using 
> >> these packages.
> >
> > I've re-read this a couple of times and I'm still confused on what you
> > meant by an "update batch"?  And provided by whom?
> >
>
>  He wants Red Hat to include EPEL as a repository by default. By 
>  "update batch", he is referring to the sync updates like 5.1. This 
>  needs to be discussed with product management. I will let you know if 
>  and when there is a change.
>
>  Rahul
>  
Yes, that's exactly what I meant.

Though from the discussion you two are having, it may seem as if this is 
going to be an "at your own risk" sort of thing for RHEL users. I 
certainly hope it will not be that way. Make EPEL move as slowly as RHEL 
and to test each package as thoroughly as they test each RHEL release, 
just bring the myriad of awesome packages that live in the repos to RHEL 
users. I'd venture to guess that this would be a good thing for 
corporate desktop users, and even those few who choose to user RHEL for 
their home systems.

[Bryan Smith]

On Mon, 2007-07-30 at 21:01 -0500, Gian Paolo Mureddu wrote:
>  Though from the discussion you two are having, it may seem as if this
> is 
>  going to be an "at your own risk" sort of thing for RHEL users. I 
>  certainly hope it will not be that way. 
There is a huge difference between a "7 year RHEL maintained
package" (with full SLA option) and a "Fedora package maintainer."

I have no problem with EPEL as an offering.  But I don't see it going
into RHEL as "stock" -- especially not at the "update" level.  As I
hinted before, the last thing I'd want to do deal with if I was a Red
Hat consultant is a failed update due to a deprecated/unmaintained EPEL
package.

>  Make EPEL move as slowly as RHEL and to test each package as
> thoroughly
>  as they test each RHEL release, 
Then at what point do RHEL maintainers just take over the package?
Unless I'm mistaken, it's hard for Red Hat to rely on Fedora maintainers
when it comes to RHEL.

I know there are many inside of Red Hat that _do_ wear _both_ hats.  But
while virtually any RHEL package is in Fedora, it's _not_ the other way
around -- very not so!  ;)

I don't see how EPEL can be anything but an augment, not a standard,
part of RHEL.  I honestly don't.  CentOS, different story.  But as far
as RHEL, I don't see it.
 
>  just bring the myriad of awesome packages that live in the repos to
> RHEL 
>  users. I'd venture to guess that this would be a good thing for 
>  corporate desktop users, and even those few who choose to user RHEL for 
>  their home systems. 
Then you don't understand the focus of RHEL -- at least as I've come to
know it.  RHEL's focus is _not_ the same as CentOS, despite CentOS being
built from RHEL.

That is the _key_ to understanding my point.  ;->

RHEL is _not_ about package availability.  It's about guaranteed ABI/API
compatibility, integration testing, regression mitigation, etc..., with
optional SLAs, for 7 years.

But I'm just an outsider, and don't speak for anyone but myself and my
exposure.


-- 
Bryan J. Smith         Professional, Technical Annoyance
mailto:[e-mail]   http://thebs413.blogspot.com
--------------------------------------------------------
        Fission Power:  An Inconvenient Solution

[Karsten Wade]

On Mon, 2007-07-30 at 08:55 -0400, Bryan J. Smith wrote:

>  I know.  At the same time, if I was a Red Hat consultant on client
> site,
>  I wouldn't have to deal with the pressure of a SLA only to find out
>  there was breakage caused by EPEL.  I'm not saying EPEL will "break,"
>  but from the "anal power," there is that "risk." 
Well, we know this happens anyway, just people are pulling (and
rebuilding) packages from all sorts of random locations.

EPEL is actually a great way for a consultant to help a company get a
desired package available.  One of the reasons for this "standard job
description":

http://fedoraproject.org/wiki/EPEL/PackageMaintainer/GenericJobDescription

- Karsten
-- 
   Karsten Wade, 108 Editor       ^     Fedora Documentation Project 
 Sr. Developer Relations Mgr.     |  fedoraproject.org/wiki/DocsProject
   quaid.108.redhat.com           |          gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

[Bryan Smith]

On Mon, 2007-07-30 at 22:01 -0700, Karsten Wade wrote:
>  Well, we know this happens anyway, just people are pulling (and
>  rebuilding) packages from all sorts of random locations. 
Oh, I wholly agree this is drastically improved.  The Fedora standards
and processes are much, much better than your typical "oh, it built"
attitude of select RPMForge/3rd Party repositories.

>  EPEL is actually a great way for a consultant to help a company get
> a
>  desired package available.  One of the reasons for this "standard job
>  description":
>  http://fedoraproject.org/wiki/EPEL/PackageMaintainer/GenericJobDescription 
An EPEL package could become stale or otherwise cause an update to fail,
etc...  Especially if it is a dependency for another EPEL package that
is still being maintained, etc...

Now I understand there are no "alternative" packages to what is in RHEL
and no RHEL package can be replaced or dependent on a EPEL package.  But
there's still that issue.


-- 
Bryan J. Smith         Professional, Technical Annoyance
mailto:[e-mail]   http://thebs413.blogspot.com
--------------------------------------------------------
        Fission Power:  An Inconvenient Solution

[Manuel Wolfshant]

Bryan J. Smith wrote:
>  On Mon, 2007-07-30 at 22:01 -0700, Karsten Wade wrote:
>    
> > Well, we know this happens anyway, just people are pulling (and
> > rebuilding) packages from all sorts of random locations.
> >     
>
>  Oh, I wholly agree this is drastically improved.  The Fedora standards
>  and processes are much, much better than your typical "oh, it built"
>  attitude of select RPMForge/3rd Party repositories.
>     
Sorry to contradict you, but you are not fair. The attitude in major 3rd 
party repos is far from "oh, it built". I am constantly using several of 
them (especially rpmforge, sometimes atrpms, centosplus and kb) for a 
couple of years and the number of problems created by them was very very 
low. And the quality of specs for many of the packages in those 
repositories is lots of times excellent. I know I repeat myself, but 
axel, dag,dries, hughes jr, karanbir,and thias (alphabetically listed) 
do a great job and I am once again happy to extend my thanks to them for 
their work.


> > EPEL is actually a great way for a consultant to help a company
> get a
> > desired package available.  One of the reasons for this "standard job
> > description":
> > http://fedoraproject.org/wiki/EPEL/PackageMaintainer/GenericJobDescription
> >     
>
>  An EPEL package could become stale or otherwise cause an update to fail,
>  etc...  Especially if it is a dependency for another EPEL package that
>  is still being maintained, etc...
>
>  Now I understand there are no "alternative" packages to what is in RHEL
>  and no RHEL package can be replaced or dependent on a EPEL package.  But
>  there's still that issue. 
EPEL is just an effort to bring in the RHEL world the
packages from the 
former Fedora Extras while also trying to the best of our (I speak now 
as a Fedora Collection maintainer and as a member of EPEL SIG ) 
abilities to also respect the long term commitment of RHEL (in terms of 
ABI etc).

[Bryan Smith]

On Tue, 2007-07-31 at 17:54 +0300, Manuel Wolfshant wrote:
>  Sorry to contradict you, but you are not fair. The attitude in major
> 3rd 
>  party repos is far from "oh, it built". 
I specifically said "select RPMForge/3rd Party repositories".
                     ^^^^^^
I *DO* give kudos to _several_ RPMForge/3rd Party repositories when it
is due.  That's why I said "select".  _Remember_ my context here, RHEL
with optional SLAs.  ;)

But there *ARE* _several_ ones that do not want to deal with Red
Hat/Fedora processes.  They were quite critical of them when Fedora
Extras first started up.  I was rather disgusted at the "attitudes" they
had towards Red Hat's "requirements" on Fedora Extras, because it was
about ensuring some basic level of integration testing, not just "a
package dump."

>  I am constantly using several of them (especially rpmforge,
> sometimes
>  atrpms, centosplus and kb) 
First off, I have _nothing_ negative to say about "CentOS Plus" (some of
the more "fringe" CentOS stuff is another story though -- thank God for
EPEL ;).

Secondly, I use ATrpms myself too.

But, third, I do _not_ put _either_ of them in my YUM repo.d blindly.
If I do, I pigeon-hole them for _specific_ RPMs (e.g., madwifi).

Which all goes to ... fourth ... I wouldn't like the idea of doing a
RHEL update at a client under SLA contract when they have various EPEL
packages installed (much less RPMForge/3rd Party).

>  And the quality of specs for many of the packages in those 
>  repositories is lots of times excellent. 
A SPEC file might be well designed (and I *DO* like RPMForge for that --
good "peer support"), but that doesn't mean the end product is still
well integration tested.  ;)

In other words, when I tap a SPEC file, I don't merely just "build and
release."  I actually do an integration and regression test.

There is a reason why Red Hat backports fixes for RHEL packages.  Are
EPEL maintainers going to do the same to guarantee 7 years for complete
ABI/API compatibility?

Microsoft constantly harps on the reality that independent software
quality is one thing, but integration and regression testing is another.
They are correct.  At the same time, their statements are rather
self-defeating when you start comparing Windows Professional or Server
to RHEL/RHD -- because you get both individual software quality combined
with integration and regression testing and a massive effort to ensure
long-term ABI/API compatibility to an anal power.

[ SIDE NOTE:  The key to combating Microsoft FUD is not to call their
statements lies, but to explain them.  In the overwhelming majority of
cases, their own FUD is their worst enemy. ]

>  I know I repeat myself, but axel, dag,dries, hughes jr, karanbir,and
> thias
>  (alphabetically listed) do a great job and I am once again happy to
>  extend my thanks to them for their work. 
Sigh ... I'm _so_tired_ of seeing my words twisted into things they are
_not_.  No offense, but since some people don't seem to "get it" ...

1.  I didn't build my consulting rep on just "oh, I got this package and
it works!"  At the same time ...

2.  Just because I don't put Axel, DAG, Dries, etc... in my default YUM
repos does *NOT* mean I don't think they are excellent resources or use
them regularly.

*PLEASE* stop reading into my statements!

>  EPEL is just an effort to bring in the RHEL world the packages from
> the 
>  former Fedora Extras while also trying to the best of our (I speak now 
>  as a Fedora Collection maintainer and as a member of EPEL SIG ) 
>  abilities to also respect the long term commitment of RHEL (in terms of 
>  ABI etc). 
And I _do_ appreciate that.  But there is a "line to be drawn."

At some point, the "convenience" of putting EPEL in as a "default
repository" in RHEL might also be a _burden_ on Red Hat, its consultants
and those who implement its SLA guarantees.  ;)

That's _all_ I was pointing out.  Sigh.  I guess I just spent too many
years in defense and aerospace systems.  ;)

-- 
Bryan J. Smith         Professional, Technical Annoyance
mailto:[e-mail]   http://thebs413.blogspot.com
--------------------------------------------------------
        Fission Power:  An Inconvenient Solution

Mitigating risk -- WAS: Red Hat Launches New Package Repository for Enterprise Linux

[Bryan Smith]

On Tue, 2007-07-31 at 13:33 -0400, Bryan J. Smith wrote:
>  I *DO* give kudos to _several_ RPMForge/3rd Party repositories when
> it
>  is due.  That's why I said "select".  _Remember_ my context here, RHEL
>  with optional SLAs.  ;)
>    ...  
>  Sigh ... I'm _so_tired_ of seeing my words twisted into things they are
>  _not_.  No offense, but since some people don't seem to "get it" ...
>  1.  I didn't build my consulting rep on just "oh, I got this package and
>  it works!"  At the same time ...
>  2.  Just because I don't put Axel, DAG, Dries, etc... in my default YUM
>  repos does *NOT* mean I don't think they are excellent resources or use
>  them regularly.
>  *PLEASE* stop reading into my statements! 
In re-reading several posts again, just to ensure I wasn't "wrong" in my
analysis and responses, I want to point out the thing people aren't
seeing what I'm saying.

My #1 job, as an enterprise Linux consultant -- more than anything -- is
to "mitigate risk."  That transcends "convenience."  That is what
defines my statements.

People are taking "offense" to my statements, no matter how I try to
qualify with them with prefixes like "select" or otherwise.  No matter
how I try to make it about "risk."  It's not that I'm saying anything
is
"broken" or "wrong," but about "risk."

And if that still doesn't explain what I'm trying to say, then maybe a
little'ole "devil's advocate" is all I'm doing.  I.e.,

- Adding anything not in RHEL or certified against it is a risk
- Having additional packages added to RHEL is a risk when updating
- EPEL mitigates some of that risk more than independent repositories
- But EPEL still doesn't have the guarantees of RHEL itself

That is _all_.  That's not to criticize anyone.  There's _no_way_
RPMForge/3rd Party repositories could even attempt to address the level
of risk I'm talking about.  And that's not to say there is no place for
them.  In fact, I _truly_appreciate_ (and _professionally_ use) RPMForge
myself.

And if that still doesn't explain "why," understand this whole
"exchange" started with this post ...

https://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00071....  

With my response asking for "clarification" ...

https://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00074....  

And Rahul's "verification" of what I thought he said (or as Rahul
interpreted, which I thought was correct, but I wanted someone else to
verify they saw it as I did) ...

https://www.redhat.com/archives/fedora-marketing-list/2007-July/msg00076....  

Now if that doesn't explain why I have been responding, I don't know
what will.  It's threads like this that I get the label of "jerk" by
many people.  At the same time, it's also threads like this that I get a
_lot_ of work too.  ;)

Why?

Because what may matter to 97% of the community is not what matters to
another 3%.  And those 3% are the people who pay my mortgage.  I am
_not_ criticizing the efforts of _anyone_, I'm merely pointing out why
EPEL may not be "enabled" by default in RHEL.  And that's where my focus
is.

Because I built my reputation on that 3%, even if I've managed to piss
off 97%.  Not my intent at all, and I wish people would stop
interpreting my "risk" comments which, are indeed sometimes
"critical" (but very _exact_ and _qualifying_), as a "dislike." 
It's so
far from the truth it's not even funny!

E.g., I couldn't live without RPMForge.  But, at the same time, I think
RHEL should live without EPEL "enabled" by default.

If you can't see that careful, critical analysis by myself, I don't know
what to tell you.  I'm not trying to insult or belittle anyone.  But
just point out that when it comes to my job -- risk mitigation -- I have
to make hard choices.

As always, I'm an outsider and don't speak for anyone but myself.

-- 
Bryan J. Smith         Professional, Technical Annoyance
mailto:[e-mail]   http://thebs413.blogspot.com
--------------------------------------------------------
        Fission Power:  An Inconvenient Solution

Mitigating risk -- WAS: Red Hat Launches New Package Repository for Enterprise Linux

[Jesse Keating]

On Tue, 31 Jul 2007 13:49:42 -0400
"Bryan J. Smith" <b.j.smith(a)ieee.org&gt; wrote:

>  And if that still doesn't explain what I'm trying to say,
> then maybe a
>  little'ole "devil's advocate" is all I'm doing.  I.e.,
>  
>  - Adding anything not in RHEL or certified against it is a risk
>  - Having additional packages added to RHEL is a risk when updating
>  - EPEL mitigates some of that risk more than independent repositories
>  - But EPEL still doesn't have the guarantees of RHEL itself 
I have to agree 100%.

-- 
Jesse Keating RHCE      (jkeating.livejournal.com)
Fedora Project          (fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)

[Rahul Sundaram]

Gian Paolo Mureddu wrote:

> >
>  Yes, that's exactly what I meant.
>  
>  Though from the discussion you two are having, it may seem as if this is 
>  going to be an "at your own risk" sort of thing for RHEL users. 
Yes. That is the *best* we can hope for.  RHEL is a commercial product 
that comes with support, warranty and services with tedious level of 
backporting, testing etc that guarantees a level of ABI compatibility, 
hardware and software certifications and that is it's value over the 
hundreds of other distributions out there. These are legally enforceable 
requirements specified in a contract. Anything that is not directly 
maintained is going to be automatically excluded. Some security 
certifications also require you all the software and every single check 
in a product to be done by a single vendor and you need to able to 
verify and prove that to get certified and without those certifications 
you are excluded from some specific markets - defense, government, 
financial etc.

So yes, EPEL is not going to be treated as part of the same product with 
commercial support regardless of it's quality since it is volunteer 
work. See EPEL FAQ for more details.

Rahul

[Bryan Smith]

On Tue, 2007-07-31 at 23:36 +0530, Rahul Sundaram wrote:
>  So yes, EPEL is not going to be treated as part of the same product
> with 
>  commercial support regardless of it's quality since it is volunteer 
>  work. See EPEL FAQ for more details. 
And that's the "hard part" when it comes to selling portions of Red Hat
on "enabling" EPEL by default.  Even "harder" is the very question
originally brought up (now re-phrased by myself here) ...

  How does one mitigate risk of updating RHEL _with_ EPEL?  
  Especially if and when SLAs are involved?  

Understand everything I'm pointing out is not just to "be a jerk."  And
it's not just to play "devil's advocate."  Hell, I'm not even
really
trying to "be Red Hat" in asking those question.

Of more consideration and direct actions by myself ...

  Can I get my clients the non-RHEL/non-certified software they need?
  And without putting any additional burden on Red Hat and their SLAs?

That's not being critical of any efforts by Fedora or any 3rd Parties.
That's being critical of the risks involved, period, with the utmost
consideration of not just my clients, not just Red Hat, but Fedora
volunteers.

Anyway, time for me to STFU.  ;)


-- 
Bryan J. Smith         Professional, Technical Annoyance
mailto:[e-mail]   http://thebs413.blogspot.com
--------------------------------------------------------
        Fission Power:  An Inconvenient Solution

[Rahul Sundaram]

Bryan J. Smith wrote:
>  On Tue, 2007-07-31 at 23:36 +0530, Rahul Sundaram wrote:
> > So yes, EPEL is not going to be treated as part of the same product with 
> > commercial support regardless of it's quality since it is volunteer 
> > work. See EPEL FAQ for more details.
>  
>  And that's the "hard part" when it comes to selling portions of Red Hat
>  on "enabling" EPEL by default.  Even "harder" is the very question
>  originally brought up (now re-phrased by myself here) ...
>  
>    How does one mitigate risk of updating RHEL _with_ EPEL?  
>    Especially if and when SLAs are involved?   
There are multiple ways to manage this. One is that Red Hat ships the 
repository but disables it by default and then specifically excludes 
EPEL from the SLA like it does with the supplementary channel.

If a customer chooses to enable it, then they are aware of the benefit 
and risks involved.

Rahul