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