On 6/3/21 4:43 AM, Stefan Hajnoczi wrote:
On Wed, Jun 02, 2021 at 12:09:47PM -0400, John Snow wrote:
On 6/2/21 5:22 AM, Stefan Hajnoczi wrote:
On Fri, May 21, 2021 at 01:38:17PM -0400, John Snow wrote:
+## Host environment
+ - Operating system: (Windows 10 21H1, Fedora 34, etc.)
+ - OS/kernel version: (For POSIX hosts, use `uname -a`)
+ - Architecture: (x86, ARM, s390x, etc.)
+ - QEMU flavor: (qemu-system-x86_64, qemu-aarch64, qemu-img, etc.)
Is this necessary since we ask for the command-line below?
Not strictly, IF the entire form is filled out. I had noticed some bugs in
gitlab where reporters seem to be aware of what kind of QEMU they are
running, but are unable to procure the command line invocation. (it is being
launched through docker, virsh, etc.) *
It's redundant, but I am operating on the belief that the CLI may not always
be available. I don't expect people to not file a bug because they can't
find it.
I think of it as a prompt to get a more detailed report on the first try. Is
it worth keeping?
*(Aside: maybe a wiki "how to report a bug" page could have a small section
on identifying the command line arguments when QEMU is being launched via
vmm/boxes/virsh/docker and so on.)
It didn't occur to me that the fields were optional :).
For me personally, long bug reporting templates reduce the chance that I
will report a bug.
Stefan
Yeah, it's a delicate balance. I want to imply they're mandatory. I
don't want to call them optional, because then people may not feel
compulsed to spend the effort to fill them out. I want them to feel a
little compulsed. :)
On the other hand, sometimes these fields just won't apply, or there are
reasons you can't fill them all out. A lot of reporters do not know how
to build QEMU from source, or repeat a libvirt problem using 'raw' QEMU.
Sometimes it's OK to file a less-than-perfect report. As you say, I
don't want the barrier of entry to be too high.
Adding more instructions like "Hey, this field is optional if you have a
CLI for us" just makes the template even longer and perhaps more
intimidating, so I tried to keep it brief. Not my specialty ...
There's kind of a weird balance of implying things going on here. I
suspect we will just have to try one approach and then change it as we
observe how it gets used.
Don't think I'll solve it from the privacy of my own mind :)
Thanks for looking.
--js
