[PATCH v3 0/2] Gitlab: Add issue templates

[PATCH v3 0/2] Gitlab: Add issue templates

[John Snow]

Add "Bug" and "Feature Request" templates to the Gitlab interface to
help improve the quality of newly reported issues.

To see what this looks like, I've temporarily allowed my Gitlab fork to
diverge with these files merged.  See my fork's "new issue" page to see
it in action: https://gitlab.com/jsnow/qemu/-/issues/new?issue

These patches do not add a "default" template, the user still has to
select one from the list. I recommend that someone with permissions
updates the default template:

1. https://gitlab.com/qemu-project/qemu/edit
2. ctrl+f "Default description template for issues"
3. Update the default to the (suggested) below:

```
<!-- Select "Type: Issue" and choose one of the Description templates above. -->
```

We can use this cover letter to discuss/review the wording on that
default template which exists outside of repository data.

V3:
 - Add pointer to https://www.qemu.org/download/#source
 - Add pointer to https://www.qemu.org/contribute/security-process/
 - Remove blurb covering tracing instructions.

V2:
- Updated both templates based on feedback from Peter, Daniel, and
  Thomas.

John Snow (2):
  GitLab: Add "Bug" issue reporting template
  GitLab: Add "Feature Request" issue template.

 .gitlab/issue_templates/bug.md             | 63 ++++++++++++++++++++++
 .gitlab/issue_templates/feature_request.md | 32 +++++++++++
 2 files changed, 95 insertions(+)
 create mode 100644 .gitlab/issue_templates/bug.md
 create mode 100644 .gitlab/issue_templates/feature_request.md

-- 
2.31.1

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

[John Snow]

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

[PATCH v3 2/2] GitLab: Add "Feature Request" issue template.

[John Snow]

Based on Peter Krempa's libvirt template, feature.md.

CC: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 .gitlab/issue_templates/feature_request.md | 32 ++++++++++++++++++++++
 1 file changed, 32 insertions(+)
 create mode 100644 .gitlab/issue_templates/feature_request.md

diff --git a/.gitlab/issue_templates/feature_request.md b/.gitlab/issue_templates/feature_request.md
new file mode 100644
index 00000000000..fc58ca27634
--- /dev/null
+++ b/.gitlab/issue_templates/feature_request.md
@@ -0,0 +1,32 @@
+<!--
+This is the upstream QEMU issue tracker.
+
+Please note that QEMU, like most open source projects, relies on
+contributors who have motivation, skills and available time to work on
+implementing particular features.
+
+Feature requests can be helpful for determining demand and interest, but
+they are not a guarantee that a contributor will volunteer to implement
+it. We welcome and encourage even draft patches to implement a feature
+be sent to the mailing list where it can be discussed and developed
+further by the community.
+
+Thank you for your interest in helping us to make QEMU better!
+-->
+
+## Goal
+<!-- Describe the final result you want to achieve. Avoid design specifics. -->
+
+
+## Technical details
+<!-- Describe technical details, design specifics, suggestions, versions, etc. -->
+
+
+## Additional information
+
+
+<!--
+The line below ensures that proper tags are added to the issue.
+Please do not remove it.
+-->
+/label ~"kind::Feature Request"
-- 
2.31.1

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

[Thomas Huth]

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>

Re: [PATCH v3 2/2] GitLab: Add "Feature Request" issue template.

[Thomas Huth]

On 03/06/2021 02.11, John Snow wrote:
> Based on Peter Krempa's libvirt template, feature.md.
> 
> CC: Peter Krempa <pkrempa@redhat.com>
> Signed-off-by: John Snow <jsnow@redhat.com>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
>   .gitlab/issue_templates/feature_request.md | 32 ++++++++++++++++++++++
>   1 file changed, 32 insertions(+)
>   create mode 100644 .gitlab/issue_templates/feature_request.md

Reviewed-by: Thomas Huth <thuth@redhat.com>

Re: [PATCH v3 0/2] Gitlab: Add issue templates

[Philippe Mathieu-Daudé]

On 6/3/21 2:11 AM, John Snow wrote:
> John Snow (2):
>   GitLab: Add "Bug" issue reporting template
>   GitLab: Add "Feature Request" issue template.
> 
>  .gitlab/issue_templates/bug.md             | 63 ++++++++++++++++++++++
>  .gitlab/issue_templates/feature_request.md | 32 +++++++++++
>  2 files changed, 95 insertions(+)

Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>

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

[Philippe Mathieu-Daudé]

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"
> 

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]

On Wed, Jun 02, 2021 at 08:11:28PM -0400, 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.

It's likely that those unfamiliar with QEMU, especially non-developers,
won't be able to do this:

The wording requires the reader to figure out that "latest development
version of QEMU" is none of the big 6.0.0, 5.2.0, etc download links at
the top of the page but the small text "The latest development happens
on the master branch" sentence below the fold. Then they need to look
around the page to find out how to download the master branch and build
from source.

I suggest referring directly to the build instructions instead of
requiring the reader to make several connections in order to do what
we're (indirectly) asking:

  Before submitting a bug, please attempt to reproduce the problem with
  the latest qemu.git master built from source. See the "To download and
  build QEMU from git" section at https://www.qemu.org/download/#source
  for instructions.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Daniel P. Berrangé]

On Thu, Jun 03, 2021 at 09:45:43AM +0100, Stefan Hajnoczi wrote:
> On Wed, Jun 02, 2021 at 08:11:28PM -0400, 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.
> 
> It's likely that those unfamiliar with QEMU, especially non-developers,
> won't be able to do this:
> 
> The wording requires the reader to figure out that "latest development
> version of QEMU" is none of the big 6.0.0, 5.2.0, etc download links at
> the top of the page but the small text "The latest development happens
> on the master branch" sentence below the fold. Then they need to look
> around the page to find out how to download the master branch and build
> from source.
> 
> I suggest referring directly to the build instructions instead of
> requiring the reader to make several connections in order to do what
> we're (indirectly) asking:
> 
>   Before submitting a bug, please attempt to reproduce the problem with
>   the latest qemu.git master built from source. See the "To download and
>   build QEMU from git" section at https://www.qemu.org/download/#source
>   for instructions.

I do wonder if this will discourage people from submitting  a bug report,
if they're unable to actually do this. We have a fairly frequent stream
of users who seek help trying to build QEMU - usually they fail to even
get the right depedancies installed.

Perhaps word it so it doesn't come across as such a strict sounding
requirement ? I'm not entirely happy with the below text, but something
more forgiving like:

   If you are able to, it will facilitate QEMU bug triage if an attempt
   is made to reproduce the problem with the latest qemu.git master
   built from source. ...etc..

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 :|

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 2742 bytes --]

On Thu, Jun 03, 2021 at 10:20:24AM +0100, Daniel P. Berrangé wrote:
> On Thu, Jun 03, 2021 at 09:45:43AM +0100, Stefan Hajnoczi wrote:
> > On Wed, Jun 02, 2021 at 08:11:28PM -0400, 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.
> > 
> > It's likely that those unfamiliar with QEMU, especially non-developers,
> > won't be able to do this:
> > 
> > The wording requires the reader to figure out that "latest development
> > version of QEMU" is none of the big 6.0.0, 5.2.0, etc download links at
> > the top of the page but the small text "The latest development happens
> > on the master branch" sentence below the fold. Then they need to look
> > around the page to find out how to download the master branch and build
> > from source.
> > 
> > I suggest referring directly to the build instructions instead of
> > requiring the reader to make several connections in order to do what
> > we're (indirectly) asking:
> > 
> >   Before submitting a bug, please attempt to reproduce the problem with
> >   the latest qemu.git master built from source. See the "To download and
> >   build QEMU from git" section at https://www.qemu.org/download/#source
> >   for instructions.
> 
> I do wonder if this will discourage people from submitting  a bug report,
> if they're unable to actually do this. We have a fairly frequent stream
> of users who seek help trying to build QEMU - usually they fail to even
> get the right depedancies installed.
> 
> Perhaps word it so it doesn't come across as such a strict sounding
> requirement ? I'm not entirely happy with the below text, but something
> more forgiving like:
> 
>    If you are able to, it will facilitate QEMU bug triage if an attempt
>    is made to reproduce the problem with the latest qemu.git master
>    built from source. ...etc..

Sounds good.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[John Snow]

On 6/3/21 7:52 AM, Stefan Hajnoczi wrote:
> On Thu, Jun 03, 2021 at 10:20:24AM +0100, Daniel P. Berrangé wrote:
>> On Thu, Jun 03, 2021 at 09:45:43AM +0100, Stefan Hajnoczi wrote:
>>> On Wed, Jun 02, 2021 at 08:11:28PM -0400, 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.
>>>
>>> It's likely that those unfamiliar with QEMU, especially non-developers,
>>> won't be able to do this:
>>>
>>> The wording requires the reader to figure out that "latest development
>>> version of QEMU" is none of the big 6.0.0, 5.2.0, etc download links at
>>> the top of the page but the small text "The latest development happens
>>> on the master branch" sentence below the fold. Then they need to look
>>> around the page to find out how to download the master branch and build
>>> from source.
>>>
>>> I suggest referring directly to the build instructions instead of
>>> requiring the reader to make several connections in order to do what
>>> we're (indirectly) asking:
>>>
>>>    Before submitting a bug, please attempt to reproduce the problem with
>>>    the latest qemu.git master built from source. See the "To download and
>>>    build QEMU from git" section at https://www.qemu.org/download/#source
>>>    for instructions.
>>
>> I do wonder if this will discourage people from submitting  a bug report,
>> if they're unable to actually do this. We have a fairly frequent stream
>> of users who seek help trying to build QEMU - usually they fail to even
>> get the right depedancies installed.
>>
>> Perhaps word it so it doesn't come across as such a strict sounding
>> requirement ? I'm not entirely happy with the below text, but something
>> more forgiving like:
>>
>>     If you are able to, it will facilitate QEMU bug triage if an attempt
>>     is made to reproduce the problem with the latest qemu.git master
>>     built from source. ...etc..
> 
> Sounds good.
> 
> Stefan
> 

I agree, thank you for this suggestion. I will work this in.

--js

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

[John Snow]

On 6/3/21 5:20 AM, Daniel P. Berrangé wrote:
> On Thu, Jun 03, 2021 at 09:45:43AM +0100, Stefan Hajnoczi wrote:
>> On Wed, Jun 02, 2021 at 08:11:28PM -0400, 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.
>>
>> It's likely that those unfamiliar with QEMU, especially non-developers,
>> won't be able to do this:
>>
>> The wording requires the reader to figure out that "latest development
>> version of QEMU" is none of the big 6.0.0, 5.2.0, etc download links at
>> the top of the page but the small text "The latest development happens
>> on the master branch" sentence below the fold. Then they need to look
>> around the page to find out how to download the master branch and build
>> from source.
>>
>> I suggest referring directly to the build instructions instead of
>> requiring the reader to make several connections in order to do what
>> we're (indirectly) asking:
>>
>>    Before submitting a bug, please attempt to reproduce the problem with
>>    the latest qemu.git master built from source. See the "To download and
>>    build QEMU from git" section at https://www.qemu.org/download/#source
>>    for instructions.
> 
> I do wonder if this will discourage people from submitting  a bug report,
> if they're unable to actually do this. We have a fairly frequent stream
> of users who seek help trying to build QEMU - usually they fail to even
> get the right depedancies installed.
> 
> Perhaps word it so it doesn't come across as such a strict sounding
> requirement ? I'm not entirely happy with the below text, but something
> more forgiving like:
> 
>     If you are able to, it will facilitate QEMU bug triage if an attempt
>     is made to reproduce the problem with the latest qemu.git master
>     built from source. ...etc..
> 
> Regards,
> Daniel
> 

How about:


If you are able to, it will greatly facilitate bug triage if you attempt
to reproduce the problem with the latest qemu.git master 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 on
https://www.qemu.org/. Problems with distro-packaged versions of QEMU
older than this should be reported to the distribution instead.


- I put an emphasis on facilitate (It's in YOUR interest to do this.)
- I rephrased "if an attempt is made to" to "if you attempt to", a less
   passive (and shorter) sentence.

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

[Daniel P. Berrangé]

On Thu, Jun 03, 2021 at 10:44:13AM -0400, John Snow wrote:
> On 6/3/21 5:20 AM, Daniel P. Berrangé wrote:
> > On Thu, Jun 03, 2021 at 09:45:43AM +0100, Stefan Hajnoczi wrote:
> > > On Wed, Jun 02, 2021 at 08:11:28PM -0400, 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.
> > > 
> > > It's likely that those unfamiliar with QEMU, especially non-developers,
> > > won't be able to do this:
> > > 
> > > The wording requires the reader to figure out that "latest development
> > > version of QEMU" is none of the big 6.0.0, 5.2.0, etc download links at
> > > the top of the page but the small text "The latest development happens
> > > on the master branch" sentence below the fold. Then they need to look
> > > around the page to find out how to download the master branch and build
> > > from source.
> > > 
> > > I suggest referring directly to the build instructions instead of
> > > requiring the reader to make several connections in order to do what
> > > we're (indirectly) asking:
> > > 
> > >    Before submitting a bug, please attempt to reproduce the problem with
> > >    the latest qemu.git master built from source. See the "To download and
> > >    build QEMU from git" section at https://www.qemu.org/download/#source
> > >    for instructions.
> > 
> > I do wonder if this will discourage people from submitting  a bug report,
> > if they're unable to actually do this. We have a fairly frequent stream
> > of users who seek help trying to build QEMU - usually they fail to even
> > get the right depedancies installed.
> > 
> > Perhaps word it so it doesn't come across as such a strict sounding
> > requirement ? I'm not entirely happy with the below text, but something
> > more forgiving like:
> > 
> >     If you are able to, it will facilitate QEMU bug triage if an attempt
> >     is made to reproduce the problem with the latest qemu.git master
> >     built from source. ...etc..
> > 
> > Regards,
> > Daniel
> > 
> 
> How about:
> 
> 
> If you are able to, it will greatly facilitate bug triage if you attempt
> to reproduce the problem with the latest qemu.git master 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 on
> https://www.qemu.org/. Problems with distro-packaged versions of QEMU
> older than this should be reported to the distribution instead.
> 
> 
> - I put an emphasis on facilitate (It's in YOUR interest to do this.)
> - I rephrased "if an attempt is made to" to "if you attempt to", a less
>   passive (and shorter) sentence.

Fine with me

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 :|

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

[John Snow]

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

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

[Daniel P. Berrangé]

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 :|