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