On Thu, 2008-07-17 at 14:24 -0400, Brian Long wrote: > Unfortunately this means smaller companies are less likely to have their > critical bugs fix since they cannot afford a support contract with a > TAM. The TAM was invaluable, although he was caught between a rock and > a hard place many times. He understood our needs and wants and he had > to balance them with Red Hat's ability to fix the problems, add features > in the middle of a release, etc. > > Having dealt with Novell, Sun, NetApp, etc., I'd say Red Hat is doing a > good job in general (with room for improvement). If you're just paying > your subscription costs and don't have an established service contract, > I don't think it's much better than Bugzilla....
I should note that my initial comment was focused more an the procedural issues of handling regressions that on general support. In my mind taking 6-9 months or longer to fix a regressions is far worse than taking the same time to fix a bug. You broke something that was working, and now I have to wait months to get a fix. That's pretty hard to explain to the people paying the bills. Does Redhat EVER revert an update? I'm always told that "they are working on it" or "it's going through the QA process". Well, the QA process has already failed, at least revert the package to a previously known working state or, at a bare minimum send customers a notice. Don't keep letting customers install known broken packages weeks, and months after you know there is a problem. That's just wrong and it's not what we pay for. For example, the current issue that I posted about regarding the RHEL4 kernel crashing is a known entity being hit by many users. It was introduced in the 2.6.9-67.0.20 kernel and is a known problem with a known fix. The official Redhat response "There is a known problem with this kernel that affects some customers in certain circumstances, engineering is working on a fix and test kernels are going through QA. No kernel is released without the QA process". Well, that's great that you have a QA process, never mind that it's a process that allowed you to release a kernel that WILL BREAK at least some of your users critical systems (systems running Oracle databases seem to be at high risk, we lost 3 of 5 in less that 24 hours). In the meantime your customers are installing kernels that are likely to break their systems. Sure, perhaps it only affects 1% of systems. Shouldn't we expect Redhat to tell us that the current kernel is known to be broken? At a bare minimum, a nice "Known Issues" page for each release might be useful, with workarounds if any. That's what Cisco, and many other companies do. That way there is at least a method for users to check for known problems when they hit something. Maybe that could be a community effort. Later, Tom _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
