[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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.html  

With my response asking for "clarification" ...

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

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.html  

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:b j smith ieee org   http://thebs413.blogspot.com
--------------------------------------------------------
        Fission Power:  An Inconvenient Solution


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]