Based loosely on libvirt's template, written by Peter Krempa.
CC: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
---
.gitlab/issue_templates/bug.md | 63 ++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
create mode 100644 .gitlab/issue_templates/bug.md
diff --git a/.gitlab/issue_templates/bug.md b/.gitlab/issue_templates/bug.md
new file mode 100644
index 00000000000..9445777252b
--- /dev/null
+++ b/.gitlab/issue_templates/bug.md
@@ -0,0 +1,63 @@
+<!--
+This is the upstream QEMU issue tracker.
+
+Before submitting a bug, please attempt to reproduce your problem using
+the latest development version of QEMU, built from source. See
+https://www.qemu.org/download/#source for instructions on how to do
+this.
+
+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.
+
+If this is a security issue, please consult
+https://www.qemu.org/contribute/security-process/
+-->
+
+## 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.)
+ - QEMU version: (e.g. `qemu-system-x86_64 --version`)
+ - QEMU command line:
+ <!--
+ Give the smallest, complete command line that exhibits the problem.
+
+ If you are using libvirt, virsh, or vmm, you can likely find the QEMU
+ command line arguments in /var/log/libvirt/qemu/$GUEST.log.
+ -->
+ ```
+ ./qemu-system-x86_64 -M q35 -m 4096 -enable-kvm -hda fedora32.qcow2
+ ```
+
+## Emulated/Virtualized environment
+ - Operating system: (Windows 10 21H1, Fedora 34, etc.)
+ - OS/kernel version: (For POSIX guests, use `uname -a`.)
+ - Architecture: (x86, ARM, s390x, etc.)
+
+
+## Description of problem
+<!-- Describe the problem, including any error/crash messages seen. -->
+
+
+## Steps to reproduce
+1.
+2.
+3.
+
+
+## Additional information
+
+<!--
+Attach logs, stack traces, screenshots, etc. Compress the files if necessary.
+If using libvirt, libvirt logs and XML domain information may be relevant.
+-->
+
+<!--
+The line below ensures that proper tags are added to the issue.
+Please do not remove it.
+-->
+/label ~"kind::Bug"
--
2.31.1
On 6/3/21 2:11 AM, John Snow wrote: > Based loosely on libvirt's template, written by Peter Krempa. > > CC: Peter Krempa <pkrempa@redhat.com> > Signed-off-by: John Snow <jsnow@redhat.com> > --- > .gitlab/issue_templates/bug.md | 63 ++++++++++++++++++++++++++++++++++ > 1 file changed, 63 insertions(+) > create mode 100644 .gitlab/issue_templates/bug.md > > diff --git a/.gitlab/issue_templates/bug.md b/.gitlab/issue_templates/bug.md > new file mode 100644 > index 00000000000..9445777252b > --- /dev/null > +++ b/.gitlab/issue_templates/bug.md > @@ -0,0 +1,63 @@ > +<!-- > +This is the upstream QEMU issue tracker. > + > +Before submitting a bug, please attempt to reproduce your problem using > +the latest development version of QEMU, built from source. See > +https://www.qemu.org/download/#source for instructions on how to do > +this. > + > +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. > + > +If this is a security issue, please consult > +https://www.qemu.org/contribute/security-process/ > +--> > + > +## 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.) > + - QEMU version: (e.g. `qemu-system-x86_64 --version`) I haven't reviewed earlier version, but I wonder about the "build from sources" use case (this is not a template for distributions but for the mainstream project), so maybe add: ## Build environment (in case you built QEMU from source) - configure script command line: (e.g. ./configure --enable-nettle --disable-glusterfs --disable-user) - configure script summary output > + - QEMU command line: > + <!-- > + Give the smallest, complete command line that exhibits the problem. > + > + If you are using libvirt, virsh, or vmm, you can likely find the QEMU > + command line arguments in /var/log/libvirt/qemu/$GUEST.log. > + --> > + ``` > + ./qemu-system-x86_64 -M q35 -m 4096 -enable-kvm -hda fedora32.qcow2 > + ``` > + > +## Emulated/Virtualized environment > + - Operating system: (Windows 10 21H1, Fedora 34, etc.) > + - OS/kernel version: (For POSIX guests, use `uname -a`.) > + - Architecture: (x86, ARM, s390x, etc.) > + > + > +## Description of problem > +<!-- Describe the problem, including any error/crash messages seen. --> > + > + > +## Steps to reproduce > +1. > +2. > +3. > + > + > +## Additional information > + > +<!-- > +Attach logs, stack traces, screenshots, etc. Compress the files if necessary. > +If using libvirt, libvirt logs and XML domain information may be relevant. > +--> > + > +<!-- > +The line below ensures that proper tags are added to the issue. > +Please do not remove it. > +--> > +/label ~"kind::Bug" >
On 6/3/21 3:26 AM, Philippe Mathieu-Daudé wrote: > I haven't reviewed earlier version, but I wonder about the "build from > sources" use case (this is not a template for distributions but for the > mainstream project), so maybe add: > > ## Build environment (in case you built QEMU from source) > - configure script command line: (e.g. ./configure --enable-nettle > --disable-glusterfs --disable-user) > - configure script summary output Maybe just a little bit too much information. Even though I am pushing people to build from source, I actually think more reports are likely not to have done so. We can always ask a follow-up question if we can't reproduce without the specific configuration and a good reporter will reply ;) --js
On Thu, Jun 03, 2021 at 03:11:28PM -0400, John Snow wrote: > On 6/3/21 3:26 AM, Philippe Mathieu-Daudé wrote: > > I haven't reviewed earlier version, but I wonder about the "build from > > sources" use case (this is not a template for distributions but for the > > mainstream project), so maybe add: > > > > ## Build environment (in case you built QEMU from source) > > - configure script command line: (e.g. ./configure --enable-nettle > > --disable-glusterfs --disable-user) > > - configure script summary output > > Maybe just a little bit too much information. Even though I am pushing > people to build from source, I actually think more reports are likely not to > have done so. We need to bear in mind what % of bug reports do we actually need this information for. We don't want to be asking for information that we know is going to be irrelevant for (say) 60% of bug reports, because that wastes time of users. My gut feeling is that while configure args are useful to know in many cases, I doubt it genuinely needed for more than a relatively small percentage of bug reports. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 03/06/2021 02.11, John Snow wrote: > Based loosely on libvirt's template, written by Peter Krempa. > > CC: Peter Krempa <pkrempa@redhat.com> > Signed-off-by: John Snow <jsnow@redhat.com> > --- > .gitlab/issue_templates/bug.md | 63 ++++++++++++++++++++++++++++++++++ > 1 file changed, 63 insertions(+) > create mode 100644 .gitlab/issue_templates/bug.md Reviewed-by: Thomas Huth <thuth@redhat.com>
© 2016 - 2026 Red Hat, Inc.