Re: [PATCH v2 1/2] GitLab: Add "Bug" issue reporting template

[John Snow]

On 6/2/21 5:22 AM, Stefan Hajnoczi wrote:
> On Fri, May 21, 2021 at 01:38:17PM -0400, John Snow wrote:
> > diff --git a/.gitlab/issue_templates/bug.md b/.gitlab/issue_templates/bug.md
> > new file mode 100644
> > index 00000000000..67a02a3ffcf
> > --- /dev/null
> > +++ b/.gitlab/issue_templates/bug.md
> > @@ -0,0 +1,61 @@
> > +<!--
> > +This is the upstream QEMU issue tracker.
> > +
> > +Before submitting a bug, please attempt to reproduce your problem using
> > +the latest development version of QEMU obtained from
> > +https://gitlab.com/qemu-project/qemu/.
>
> Please be specific about what "latest development version" means. I
> guess it means qemu.git/master?

I believe that's what I was asked to strongly encourage, yes. I'll make 
that clearer.

> If we are asking them to build QEMU then it would be nice to include a
> link with instructions on how to build from source.

OK, good point. I am trying to keep it brief, so maybe I will point to a 
different wiki article. Some of our resources are a little too detailed, 
and I worry they won't get read at all.

We've got https://www.qemu.org/contribute/report-a-bug/ but I think it 
misses some items we want to address here. I could try to rework this 
page, or I could make a (very brief) "report a bug" wiki page instead.

Thoughts? (I am thinking I should at a minimum update the static page to 
be aware of the new tracker and these templates and help provide some 
clarifying instructions, but that more detailed steps ought to belong on 
the wiki, but am wary of link-rot if I link to subsections of a wiki 
article which could leave the static page links dangling.)

> > +
> > +QEMU generally supports the last two releases advertised via
> > +https://www.qemu.org/. Problems with distro-packaged versions of QEMU
> > +older than this should be reported to the distribution instead.
> > +
> > +See https://www.qemu.org/contribute/report-a-bug/ for guidance.
> > +-->
> > +
> > +## 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.)

> > +<!--
> > +Attach logs, stack traces, screenshots, etc. Compress the files if necessary.
> > +If using libvirt, libvirt logs and XML domain information may be relevant.
> > +
> > +See https://qemu-project.gitlab.io/qemu/devel/tracing.html on how to
> > +configure additional QEMU logging.
>
> This sentence can be removed. Tracing is mostly for developers and
> requires knowledge of the source code. People who can use tracing
> already know about it and for the rest it doesn't count as "additional
> QEMU logging" because they won't be able to use it effectively.

OK, I agree. We can always provide instructions here as a follow-up if 
we deem it necessary. Fodder for a wiki page somewhere.

Thanks for looking!

--js