On Fri, 2008-07-18 at 06:28 -0500, Johnny Hughes wrote: > Tom Sightler wrote:
> Another way to look at the same situation is this though (from RH's > perspective) is ... we already broke something that created the other > problem with a regression, so we don't want to make it worse with a > quick fix that breaks something else that potentially effects even more > customers than the first issue. I can understand this, but I'll make at least one couterpoint. In most cases, the regression seems to be found and identified quickly, yet Redhat continues to leave the broken package out there, allowing more and more customers to go from a working setup to a broken as they update. It feels to me like there should be a procedure to simply pull a broken update. You don't have to rush the fix, just stop breaking more machines. > > 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. > > Can you point me at a bug entry for the above issue and a its fix? https://bugzilla.redhat.com/show_bug.cgi?id=453507 (This one has the fix) https://bugzilla.redhat.com/show_bug.cgi?id=455274 (A duplicate bug entry) http://www.centos.org/modules/newbb/viewtopic.php?topic_id=15191&forum=27 (CentOS users reporting the bug) > Is that not what the Red Hat bugzilla is ??? They almost always have > advance patches available there for most issues. The problem I have > with the bugzilla is that MANY things are in there, but are marked as > PRIVATE. I think that most things should be public and only private as > a last resort. Then everyone can find the fixes if they want. I knew somebody would say this, and Bugzilla is great, there's no doubt about it, but it's biggest problem is that it's not vetted in any way. There are so many poor and incomplete bug reports, duplicates, etc, that it's difficult to determine what bugs are real and common, and which are not. There's also no consistency in how they are entered, whether they are listed as regressions, etc, which makes searching for regressions for a specific release difficult. What I'm specifically referring to would be a maintained list of currently known issues and their workarounds (if any). Maybe like a "Top 10" list of release specific bugs that their support group is seeing and their workarounds. I think that would be a hugely valuable resource. Redhat does include some "Known Issues" in their release notes, but these don't appear to be updated (perhaps I'm wrong on that). Many companies use a "live document" for their Release Notes where the Known Issues section is updated as problems are reported and workarounds created. Something like that would be great. > WRT to a community effort, CentOS does sometimes create packages for > major issues like kernels (and normally posts links to those in the > relevant RH Bugzilla entries). We do this so that the CentOS users (and > RHEL users if they want) can optionally install these fixes while > waiting for these changes to go through QA in RHEL. An example is the > recent nss_ldap issue, where we have had a fix out that SEEMS to fix > most of the issues on the day we released 5.2. Right, I'm aware that CentOS does this. Isn't it somewhat silly that the company I pay for support does not, while the community product based on it does. I do want to point out that, in the end, Redhat support is probably better than most I've dealt with, we actually do eventually get problems resolved, and most of the bugs I've filed did eventually get fixed, although several took longer than a year. My original complaint was not really intended to complain about support (if it came across that way I apologize). As the subject states, it was a request that RHEL6, and Redhat in general, focus even more on QA and their release process, in an effort to reduce regressions, and, if they exist, prioritize their response to them. We've experienced more overall regressions, and by far more critical regressions, from RHEL updates than any other product we use (Oracle is a close second), and that has damaged their reputation within the organization. I think that should be a focus. Later, Tom _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
