I sense a misconception. There is no obligation from Red Hat to act on your bug reports.
You are not a customer, you are nobody to them. To become a customer, you have to pay money, purchase licenses, purchase paid support, etc. K.O. On Mon, May 25, 2015 at 12:29:18PM -0700, ToddAndMargo wrote: > On 05/25/2015 06:42 AM, Jamie Duncan wrote: > >And that is one of the biggest issues customers can't quite > >understand. > > > >A BUG is something that acts in opposition to an application's > >documentation. If un-documented, then security risks play a role as > >well as some common sense workflow assessment. > > Hi Jamie, > > An interesting way of putting it. When a customer finds something is > unusable or badly implemented, they often think it is a bug. Or > a "virus". Quality control issues are often thought of as bugs > (I do). > > And driving you out of your mind may not be contrary to documentation, > but it is often considered a bug by the customers. I do > believe you are referring to that as "common sense workflow assessment". > > >An RFE is a request to change a documented feature in an application, > >or add a new feature. > > > >Simply disagreeing with a value (3GB for example in ext3), doesn't > >make it a bug. > > True, it makes it poorly implemented, especially since it had > been corrected in future versions. Notice I used the word "corrected" > not "enhanced"? > > The 3GB barrier is a hold over for when this was a FAT32 only > operation. They just "forgot" (bug?) to update it when they > implemented ext3 support. And if you look at the manual page > for --overlay-size-mb do you see any mention of that? It is a bug. > > And I reported it over on: > https://bugzilla.redhat.com/show_bug.cgi?id=1220015 > And I do sight documentation from the Fedora Project as to why. > > Also, the lines blur when things don't work as expected. For > instance, the USB2 slow bug in qemu-kvm. Bug or just poorly > implemented? Quality control issues can also be thought of as > bugs, not just things missing in the documentation > > >I haven't read through all of the BZ's you've posted, but the ones I > >did have time to look through were sorely lacking in information. > > Huh. I do pride myself on being a good reporter. I make sure all > the version information is stated and also a good statement of > the issue involved. Occasionally, BZ will send me a request > for information and I dutifully comply. > > I do post voluminous bugs, not just at Red Hat. One of the > things that endears me to Red Hat is their professionalism > and responsiveness to my BZ posts. (I was the one on EL5 > that discovered that burning a DVD trashed your hard drive, > the hard way, twice. Red Hat immediately jumped on it and fix > it. You can't get any better service than that.) > > >If you say something doesn't work right, point to the documentation > >where it says differently. Or point to a lack of documentation. > > > >In short, be a contributor, and not just a consumer. That, more than > > anything else, will draw attention to bugs when you file them. > > You have *no idea* the amount of unpaid hours I put into bug > reporting. *They cost me dearly.* (I see if as all part > of open source.) And, I have reminded BZ folks about that > occasionally when they make the "we are all volunteers" > argument. I am working for free too. > > BZ often times send me off on research project to narrow > down the cause of things. It takes a lot of time. I > dutifully comply. Even though financially, it is a strain, > it is gratify to be part of the process of pin pointing > and killing a bug. > > Red Hat and Libre Office have never been that unprofessional. > It is usually the Wine folks that do that. Wine never fixes > anything. They remind me of the old Open Office. (Although > Wine does send me off on constant research. And when they > pin point the issue and admit to it, do they fix it?) > > And the nature of Linux is "constant improvement" (kaizen). > It just gets better and better. BZ's are all part of kaizen. > Dr. Deming would be proud. Maybe not of the double edges > sword nature of RHEL, but still ... > > > >Also, think upstream first. It was mentioned previously, but it bears > > repeating. If you file a bug with Red Hat, they have to figure out > >what you're talking about, then look upstream > > Because of the double edges nature of the sword (the out-of-date > nature of RHEL), upstream is usually quite derisive of problems > with RHEL. With RHEL all the good points and the bad points are > frozen. And often security issues as well. For example, the > out-of-date, insecure EL6 implementations of Firefox (EL7 seems > to be keeping up). > > An example: > https://bugs.launchpad.net/qemu/+bug/1458121 > > That version was a pre-alfa version of kvm support in > qemu, is insanely outdated, is heavily patched by redhat. > I don't even think USB2 was supported by that version. > > And, I have found that when reporting a bug to Red Hat, if it is > an upstream issue, they usually tell you. For instance: > https://bugzilla.redhat.com/show_bug.cgi?id=1194936 > > >and file a bug there and get the community to agree to add/alter the > >code so we can then pull it back down into our products. Like any > >community, if more than one group points something out it is more > >likely to happen. So if you report something, and then Red Hat comes > >looking for the same thing, there is a lot more grease on the > >wheels. > > I do a combination of the two. Don't always get it perfect. I try > to figure out where is the best place to report what. The BZ's > are usually pretty nice about telling you the proper location > for something. > > For example, the USB slow bug in qemu-kvm: > > 1) asked for help on the Spice mailing list. They told me > to go to Qemu > > 2) reported it Qemu: > https://bugs.launchpad.net/qemu/+bug/1458121 > They told me it was an issue with Red Hat (Red Hat got > pretty ripped for it too) > > 3) immediately reported it to Red Hat: > https://bugzilla.redhat.com/show_bug.cgi?id=1224498 > Red Hat is currently adding folks to the CC list > > > > > HTH > > No really. > > So I can improve my BZ reporting skills, would you please pick > out a BZ you think I reported poorly and why? The last think > I want to do it to waste BZ's time. And my technical writing > skill always need "constant improvement". > > (I wonder how many typos I made in this letter.) > > Many thanks, > -T -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
