[Qemu-devel] [qemu-web PATCH] add Thomas's bug reporting dos and don'ts

[Qemu-devel] [qemu-web PATCH] add Thomas's bug reporting dos and don'ts

[Paolo Bonzini]

We don't want the page to become too long, but these are good suggestions.

Also tone down the sentence about using the latest release or latest git
tree, though we do prefer those.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 contribute.md              |  2 +-
 contribute/report-a-bug.md | 13 ++++++++++---
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/contribute.md b/contribute.md
index e052654..b10ba7f 100644
--- a/contribute.md
+++ b/contribute.md
@@ -3,7 +3,7 @@ title: Contribute to QEMU!
 permalink: /contribute/
 ---
 
-* Report a bug: https://bugs.launchpad.net/qemu/<br>[How to report a bug](report-a-bug/)
+* Report a bug: [https://bugs.launchpad.net/qemu/](https://bugs.launchpad.net/qemu/)<br>[How to report a bug](report-a-bug/)
 
 * Clone the git repository: <br>`git clone git://git.qemu-project.org/qemu.git`
 
diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
index ce73d76..81eecf7 100644
--- a/contribute/report-a-bug.md
+++ b/contribute/report-a-bug.md
@@ -3,17 +3,24 @@ title: Reporting a bug
 permalink: /contribute/report-a-bug/
 ---
 
-Bugs can be filed at our [bug tracker](https://bugs.launchpad.net/qemu/), which is hosted on Launchpad.
+Bugs can be filed at our [bug tracker](https://bugs.launchpad.net/qemu/), which is hosted on Launchpad. If you've got a problem with how your Linux distribution packages QEMU, use the bug tracker from your distro instead.
 
 When submitting a bug report, please try to do the following:
 
-* Make sure you're reporting the bug against the [latest release](/download/#source).  If possible, please try to reproduce with the latest development tree too.
+* Include the QEMU release version or the git commit hash into the description, so that it is later still clear in which version you have found the bug.  Reports against the [latest release](/download/#source) or even the latest development tree are usually acted upon faster.
 
 * Include the full command line used to launch the QEMU guest.
 
 * Reproduce the problem directly with a QEMU command-line.  Avoid frontends and management stacks, to ensure that the bug is in QEMU itself and not in a frontend.
 
-* Include as information about the guest (operating system, version, 32/64-bit).
+* Include as information about the host and guest (operating system, version, 32/64-bit).
 
 * Do not contribute patches on the bug tracker; send patches to the mailing list. Follow QEMU's [guidelines about submitting patches](http://wiki.qemu.org/Contribute/SubmitAPatch).
 
+Do NOT report security issues (or other bugs, too) as
+"private" bugs in the bug tracker.  QEMU has a [security
+process](http://wiki.qemu.org/SecurityProcess) for issues that should
+be reported in a non-public way instead.
+
+For problems with KVM in the kernel, use the kernel bug tracker instead;
+the [KVM wiki](http://www.linux-kvm.org/page/Bugs) has the details.
-- 
2.13.3

Re: [Qemu-devel] [qemu-web PATCH] add Thomas's bug reporting dos and don'ts

[Eric Blake]

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

On 07/26/2017 06:44 AM, Paolo Bonzini wrote:
> We don't want the page to become too long, but these are good suggestions.
> 
> Also tone down the sentence about using the latest release or latest git
> tree, though we do prefer those.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  contribute.md              |  2 +-
>  contribute/report-a-bug.md | 13 ++++++++++---
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 

>  * Reproduce the problem directly with a QEMU command-line.  Avoid frontends and management stacks, to ensure that the bug is in QEMU itself and not in a frontend.
>  
> -* Include as information about the guest (operating system, version, 32/64-bit).
> +* Include as information about the host and guest (operating system, version, 32/64-bit).

Grammar. Your choice of which fix to use:
s/as //
s/as information/as much information as possible/

With that fixed:
Reviewed-by: Eric Blake <eblake@redhat.com>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: [Qemu-devel] [qemu-web PATCH] add Thomas's bug reporting dos and don'ts

[Peter Maydell]

On 26 July 2017 at 12:44, Paolo Bonzini <pbonzini@redhat.com> wrote:
> We don't want the page to become too long, but these are good suggestions.
>
> Also tone down the sentence about using the latest release or latest git
> tree, though we do prefer those.

>  * Reproduce the problem directly with a QEMU command-line.  Avoid frontends and management stacks, to ensure that the bug is in QEMU itself and not in a frontend.
>
> -* Include as information about the guest (operating system, version, 32/64-bit).
> +* Include as information about the host and guest (operating system, version, 32/64-bit).

I'm not sure what the "as" here is for: should this say just
"Include information" or "Include as much information as possible"
or something else?

thanks
-- PMM

Re: [Qemu-devel] [qemu-web PATCH] add Thomas's bug reporting dos and don'ts

[Paolo Bonzini]

On 26/07/2017 13:52, Peter Maydell wrote:
>>  * Reproduce the problem directly with a QEMU command-line.  Avoid frontends and management stacks, to ensure that the bug is in QEMU itself and not in a frontend.
>>
>> -* Include as information about the guest (operating system, version, 32/64-bit).
>> +* Include as information about the host and guest (operating system, version, 32/64-bit).
> I'm not sure what the "as" here is for: should this say just
> "Include information" or "Include as much information as possible"
> or something else?

Interesting pre-existing error.  Both of them, but I think "Include
information" is lighter and flows better.

Paolo

Re: [Qemu-devel] [qemu-web PATCH] add Thomas's bug reporting dos and don'ts

[Thomas Huth]

On 26.07.2017 13:44, Paolo Bonzini wrote:
> We don't want the page to become too long, but these are good suggestions.
> 
> Also tone down the sentence about using the latest release or latest git
> tree, though we do prefer those.

Well, sometimes people still report bugs against QEMU 2.1 or so ... so
I'd say everything that is older than the current version - 2 has a very
high chance to be ignored completely. So maybe we should ask people to
use at least one of the versions that is mentioned on the front-page of
www.qemu.org ?

> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  contribute.md              |  2 +-
>  contribute/report-a-bug.md | 13 ++++++++++---
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/contribute.md b/contribute.md
> index e052654..b10ba7f 100644
> --- a/contribute.md
> +++ b/contribute.md
> @@ -3,7 +3,7 @@ title: Contribute to QEMU!
>  permalink: /contribute/
>  ---
>  
> -* Report a bug: https://bugs.launchpad.net/qemu/<br>[How to report a bug](report-a-bug/)
> +* Report a bug: [https://bugs.launchpad.net/qemu/](https://bugs.launchpad.net/qemu/)<br>[How to report a bug](report-a-bug/)
>  
>  * Clone the git repository: <br>`git clone git://git.qemu-project.org/qemu.git`
>  
> diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
> index ce73d76..81eecf7 100644
> --- a/contribute/report-a-bug.md
> +++ b/contribute/report-a-bug.md
> @@ -3,17 +3,24 @@ title: Reporting a bug
>  permalink: /contribute/report-a-bug/
>  ---
>  
> -Bugs can be filed at our [bug tracker](https://bugs.launchpad.net/qemu/), which is hosted on Launchpad.
> +Bugs can be filed at our [bug tracker](https://bugs.launchpad.net/qemu/), which is hosted on Launchpad. If you've got a problem with how your Linux distribution packages QEMU, use the bug tracker from your distro instead.
>  
>  When submitting a bug report, please try to do the following:
>  
> -* Make sure you're reporting the bug against the [latest release](/download/#source).  If possible, please try to reproduce with the latest development tree too.
> +* Include the QEMU release version or the git commit hash into the description, so that it is later still clear in which version you have found the bug.  Reports against the [latest release](/download/#source) or even the latest development tree are usually acted upon faster.
>  
>  * Include the full command line used to launch the QEMU guest.
>  
>  * Reproduce the problem directly with a QEMU command-line.  Avoid frontends and management stacks, to ensure that the bug is in QEMU itself and not in a frontend.
>

Maybe better "front-end(s)" instead of "frontend(s)" ?

> -* Include as information about the guest (operating system, version, 32/64-bit).
> +* Include as information about the host and guest (operating system, version, 32/64-bit).
>  
>  * Do not contribute patches on the bug tracker; send patches to the mailing list. Follow QEMU's [guidelines about submitting patches](http://wiki.qemu.org/Contribute/SubmitAPatch).
>  
> +Do NOT report security issues (or other bugs, too) as

Thinking about the markup again, maybe better use "*not*" instead of
"NOT" (to avoid shouting).

Apart from that, looks fine to me, thanks for the update!

 Thomas

Re: [Qemu-devel] [qemu-web PATCH] add Thomas's bug reporting dos and don'ts

[Paolo Bonzini]

On 26/07/2017 13:57, Thomas Huth wrote:
> On 26.07.2017 13:44, Paolo Bonzini wrote:
>> We don't want the page to become too long, but these are good suggestions.
>>
>> Also tone down the sentence about using the latest release or latest git
>> tree, though we do prefer those.
> 
> Well, sometimes people still report bugs against QEMU 2.1 or so ... so
> I'd say everything that is older than the current version - 2 has a very
> high chance to be ignored completely. So maybe we should ask people to
> use at least one of the versions that is mentioned on the front-page of
> www.qemu.org ?

It depends on the bug... for some, the right person might immediately
recognize that it's fixed or that it's just been reported.

Certainly a bug for RHEL6's 0.12 fork is not going to receive much
attention.  But in any case, all these recommendations are advisory
("please try to do the following").

In the end, your recommendation about including the release version or
git hash was somewhat at odds with "make sure you're reporting the bug
against the latest release" (and I actually preferred your version).
Hence the change.

Paolo

>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>> ---
>>  contribute.md              |  2 +-
>>  contribute/report-a-bug.md | 13 ++++++++++---
>>  2 files changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/contribute.md b/contribute.md
>> index e052654..b10ba7f 100644
>> --- a/contribute.md
>> +++ b/contribute.md
>> @@ -3,7 +3,7 @@ title: Contribute to QEMU!
>>  permalink: /contribute/
>>  ---
>>  
>> -* Report a bug: https://bugs.launchpad.net/qemu/<br>[How to report a bug](report-a-bug/)
>> +* Report a bug: [https://bugs.launchpad.net/qemu/](https://bugs.launchpad.net/qemu/)<br>[How to report a bug](report-a-bug/)
>>  
>>  * Clone the git repository: <br>`git clone git://git.qemu-project.org/qemu.git`
>>  
>> diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
>> index ce73d76..81eecf7 100644
>> --- a/contribute/report-a-bug.md
>> +++ b/contribute/report-a-bug.md
>> @@ -3,17 +3,24 @@ title: Reporting a bug
>>  permalink: /contribute/report-a-bug/
>>  ---
>>  
>> -Bugs can be filed at our [bug tracker](https://bugs.launchpad.net/qemu/), which is hosted on Launchpad.
>> +Bugs can be filed at our [bug tracker](https://bugs.launchpad.net/qemu/), which is hosted on Launchpad. If you've got a problem with how your Linux distribution packages QEMU, use the bug tracker from your distro instead.
>>  
>>  When submitting a bug report, please try to do the following:
>>  
>> -* Make sure you're reporting the bug against the [latest release](/download/#source).  If possible, please try to reproduce with the latest development tree too.
>> +* Include the QEMU release version or the git commit hash into the description, so that it is later still clear in which version you have found the bug.  Reports against the [latest release](/download/#source) or even the latest development tree are usually acted upon faster.
>>  
>>  * Include the full command line used to launch the QEMU guest.
>>  
>>  * Reproduce the problem directly with a QEMU command-line.  Avoid frontends and management stacks, to ensure that the bug is in QEMU itself and not in a frontend.
>>
> 
> Maybe better "front-end(s)" instead of "frontend(s)" ?
> 
>> -* Include as information about the guest (operating system, version, 32/64-bit).
>> +* Include as information about the host and guest (operating system, version, 32/64-bit).
>>  
>>  * Do not contribute patches on the bug tracker; send patches to the mailing list. Follow QEMU's [guidelines about submitting patches](http://wiki.qemu.org/Contribute/SubmitAPatch).
>>  
>> +Do NOT report security issues (or other bugs, too) as
> 
> Thinking about the markup again, maybe better use "*not*" instead of
> "NOT" (to avoid shouting).
> 
> Apart from that, looks fine to me, thanks for the update!
> 
>  Thomas
> 

Re: [Qemu-devel] [qemu-web PATCH] add Thomas's bug reporting dos and don'ts

[Daniel P. Berrange]

On Wed, Jul 26, 2017 at 01:57:35PM +0200, Thomas Huth wrote:
> On 26.07.2017 13:44, Paolo Bonzini wrote:
> > We don't want the page to become too long, but these are good suggestions.
> > 
> > Also tone down the sentence about using the latest release or latest git
> > tree, though we do prefer those.
> 
> Well, sometimes people still report bugs against QEMU 2.1 or so ... so
> I'd say everything that is older than the current version - 2 has a very
> high chance to be ignored completely. So maybe we should ask people to
> use at least one of the versions that is mentioned on the front-page of
> www.qemu.org ?

The biggest reason people would be using old versions of QEMU is if they
are running a distro's build. Such people should really file bugs in
their vendor's bug tracker, rather than against upstream directly.

IOW, it would be worth having a bit of text on the bug reporting page
to suggest people should preferrentially use their vendor's bug tracker,
if they are using a 3rd party build of QEMU.


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: [Qemu-devel] [qemu-web PATCH] add Thomas's bug reporting dos and don'ts

[Eric Blake]

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

On 07/26/2017 07:19 AM, Daniel P. Berrange wrote:
> On Wed, Jul 26, 2017 at 01:57:35PM +0200, Thomas Huth wrote:
>> On 26.07.2017 13:44, Paolo Bonzini wrote:
>>> We don't want the page to become too long, but these are good suggestions.
>>>
>>> Also tone down the sentence about using the latest release or latest git
>>> tree, though we do prefer those.
>>
>> Well, sometimes people still report bugs against QEMU 2.1 or so ... so
>> I'd say everything that is older than the current version - 2 has a very
>> high chance to be ignored completely. So maybe we should ask people to
>> use at least one of the versions that is mentioned on the front-page of
>> www.qemu.org ?
> 
> The biggest reason people would be using old versions of QEMU is if they
> are running a distro's build. Such people should really file bugs in
> their vendor's bug tracker, rather than against upstream directly.
> 
> IOW, it would be worth having a bit of text on the bug reporting page
> to suggest people should preferrentially use their vendor's bug tracker,
> if they are using a 3rd party build of QEMU.

Which was what the patch included:

> -Bugs can be filed at our [bug tracker](https://bugs.launchpad.net/qemu/), which is hosted on Launchpad.
> +Bugs can be filed at our [bug tracker](https://bugs.launchpad.net/qemu/), which is hosted on Launchpad. If you've got a problem with how your Linux distribution packages QEMU, use the bug tracker from your distro instead.

Although maybe the wording can be improved to mention that ALL bugs
about qemu packaged downstream, and not just the packaging, should be
referred to the downstream vendor (the vendor may then forward the bugs
upstream).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: [Qemu-devel] [qemu-web PATCH] add Thomas's bug reporting dos and don'ts

[Paolo Bonzini]

On 26/07/2017 14:19, Daniel P. Berrange wrote:
> On Wed, Jul 26, 2017 at 01:57:35PM +0200, Thomas Huth wrote:
>> On 26.07.2017 13:44, Paolo Bonzini wrote:
>>> We don't want the page to become too long, but these are good suggestions.
>>>
>>> Also tone down the sentence about using the latest release or latest git
>>> tree, though we do prefer those.
>>
>> Well, sometimes people still report bugs against QEMU 2.1 or so ... so
>> I'd say everything that is older than the current version - 2 has a very
>> high chance to be ignored completely. So maybe we should ask people to
>> use at least one of the versions that is mentioned on the front-page of
>> www.qemu.org ?
> 
> The biggest reason people would be using old versions of QEMU is if they
> are running a distro's build. Such people should really file bugs in
> their vendor's bug tracker, rather than against upstream directly.
> 
> IOW, it would be worth having a bit of text on the bug reporting page
> to suggest people should preferrentially use their vendor's bug tracker,
> if they are using a 3rd party build of QEMU.

There is already this sentence: "If you've got a problem with how your
Linux distribution packages QEMU, use the bug tracker from your distro
instead" but I'm not sure I'd generalize it to all bugs from a distro QEMU.

It's not like we get bugs about distro QEMUs (or bugs in general for
that matter) every day.  Most bug reports we get are from Ubuntu or
Fedora QEMUs, and they're good enough for reproduction.

Paolo