Why redhat will never get another dime of my money.

[Michael Halligan]

My last comment on this matter. Everything had been tested, and re-tested. I
imaged these 100 new servers a total of 10 times throughout a period of 5
days, and everything was stable. On the 6th day, this RPM found it's way
into satellite server due to a nightly sync.. This new software version
gets automatically added to your software images for new installs. Existing
servers require manual intervention, but new servers do not require manual
intervention. 

My bigger problem is that for 7 days after this problem existed, I received
a long run-around, until the point that this rant was necessary. I have
finally gotten the attention of RedHat, and am working with them to remedy
the problem.


On 3/30/05 12:09 PM, "Ed Wilts" <ewilts at ewilts.org> wrote:

> On Wed, Mar 30, 2005 at 09:36:14AM -0800, Michael Halligan wrote:
>> On March 15th, RedHat released a new version of rhncfg. This new
>> version, typical with redhat, was not properly qa'd, and it brought
>> our current development project to a grinding halt, making 100 servers
>> that were due to be deployed wednesday of last week unusable.
> 
> So you didn't properly test a new release that impacted 100 servers?
> Shame on you...
> 
>> I check my e-mail. Sorry. We have to put this fix through regression
>> testing, maybe on april 4th it will work.
> 
> So first you complain that they issued a release that wasn't tested
> properly, and now that they want to test a fix, you're complaining
> again?  Which would you like - a tested or untested release?
> 
>> I believe we paid $50k for satellite server, a server to run satellite
>> server, and all of our provisioning entiltements & OS licenses. The
>> irony here, is microsoft would have been cheaper. The other irony
>> here, is if this one little package were open-sourced, instead of
>> proprietary to redhat, I could have changed the ONE BROKEN LINE OF
>> CODE in the software, rebuild the package myself, and install it.
> 
> Yes, you could fix the one broken line of code.  Would you then test the
> result or just go ahead and implement in production?
> 
> Which is cheaper is totally irrelevant at this stage.  Do you seriously
> think that Microsoft releases 100% perfect software and has never issued
> a patch that breaks production environments?
> 
>> Thanks redhat, you have assured that I am moving my infrastructure to
>> SuSE & Zenworks, and that our future plans, as well as mine as a
>> consultant, will not include a software distribution with the word HAT
>> in it.
> 
> Unless you can develop testing plans, every other distributor will
> eventually cause you pain too.  Nobody releases perfect software.  Not
> Red Hat, not SuSe, not me, and probably not you.
> 
> It doesn't matter if you buy a car or software - you need to test drive
> each one and determine how it's going to react to what you're going to
> do.  If it's important to you, test it first and develop a backout
> plan.