[libvirt] [PATCH 1/1] Update bug reporting page
Dave Allan
dallan at redhat.com
Thu Feb 23 22:49:25 UTC 2012
Remove suggestion that people file bugs against RHEL 5 and add a
suggestion that people increase the visibility of their bugs by
mentioning them on libvir-list.
---
docs/bugs.html.in | 83 ++++++++++++++++++++++++++++++++++++----------------
1 files changed, 57 insertions(+), 26 deletions(-)
diff --git a/docs/bugs.html.in b/docs/bugs.html.in
index 560dfa4..39b6725 100644
--- a/docs/bugs.html.in
+++ b/docs/bugs.html.in
@@ -9,22 +9,47 @@
<h2><a name="bugzilla">Bug Tracking</a></h2>
<p>
- The <a href="http://bugzilla.redhat.com">Red Hat Bugzilla Server</a>
- should be used to report bugs and request features in libvirt.
- Before submitting a ticket, check the existing tickets to see if
- the bug/feature is already tracked.
+ If you are using libvirt binaries from a Linux distribution
+ check below for distribution specific bug reporting policies
+ first.
</p>
<h2><a name="general">General libvirt bug reports</a></h2>
<p>
- If you are using official libvirt binaries from a Linux distribution
- check below for distribution specific bug reporting policies first.
+ The <a href="http://bugzilla.redhat.com">Red Hat Bugzilla Server</a>
+ should be used to report bugs and request features in libvirt.
+ Before submitting a ticket, check the existing tickets to see if
+ the bug/feature is already tracked.
+
For general libvirt bug reports, from self-built releases, GIT snapshots
and any other non-distribution supported builds, enter tickets under
the <code>Virtualization Tools</code> product and the <code>libvirt</code>
component.
</p>
+ <p>
+ It's always a good idea to file bug reports, as the process of
+ filing the report always makes it easier to describe the
+ problem, and the bug number provides a quick way of referring to
+ the problem. However, not everybody in the community pays
+ attention to bugzilla, so after you file a bug, asking questions
+ and submitting patches on <a href="contact.html">the libvirt
+ mailing lists</a> will increase your bug's visibility and
+ encourage people to think about your problem. Don't hesitate to
+ ask questions on the list, as others may know of existing
+ solutions or be interested in collaborating with you on finding
+ a solution. Patches are always appreciated, and it's likely
+ that someone else has the same problem you do!
+ </p>
+ <p>
+ If you decide to write code, though, before you begin please
+ read the <a href="hacking.html">contributor guidelines</a>,
+ especially the first point: "Discuss any large changes on the
+ mailing list first. Post patches early and listen to feedback."
+ Few development experiences are more discouraging than spending
+ a bunch of time writing a patch only to have someone point out a
+ better approach on list.
+ </p>
<ul>
<li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&product=Virtualization%20Tools">View libvirt tickets</a></li>
@@ -34,26 +59,37 @@
<h2><a name="distribution">Linux Distribution specific bug reports</a></h2>
<ul>
<li>
- If you are using official binaries from a <strong>Fedora distribution</strong>, enter
- tickets against the <code>Fedora</code> product and the <code>libvirt</code>
- component.
+ If you are using binaries from <strong>Fedora</strong>, enter
+ tickets against the <code>Fedora</code> product and
+ the <code>libvirt</code> component.
<ul>
<li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&product=Fedora">View Fedora libvirt tickets</a></li>
<li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora&component=libvirt">New Fedora libvirt ticket</a></li>
</ul>
</li>
<li>
- If you are using official binaries from <strong>Red Hat Enterprise Linux distribution</strong>,
- tickets against the <code>Red Hat Enterprise Linux 5</code> product and
- the <code>libvirt</code> component.
- <ul>
- <li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&product=Red%20Hat%20Enterprise%20Linux%205">View Red Hat Enterprise Linux libvirt tickets</a></li>
- <li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%205&component=libvirt">New Red Hat Enterprise Linux libvirt ticket</a></li>
- </ul>
+ <p>
+ If you are using binaries from <strong>Red Hat Enterprise
+ Linux</strong>, enter tickets against the Red Hat Enterprise
+ Linux product that you're using (e.g., Red Hat Enterprise
+ Linux 6) and the <code>libvirt</code> component. Red Hat
+ bugzilla has <a href="http://bugzilla.redhat.com">additional guidance</a> about getting support if
+ you are a Red Hat customer.
+ </p>
</li>
<li>
- If you are using official binaries from another Linux distribution first
- follow their own bug reporting guidelines.
+ <p>
+ If you are using binaries from another Linux distribution
+ first follow their own bug reporting guidelines.
+ </p>
+ </li>
+ <li>
+ <p>
+ Finally, if you are a contributor to another Linux
+ distribution and would like to have your procedure for
+ filing bugs mentioned here, please mail the libvirt
+ development list.
+ </p>
</li>
</ul>
@@ -81,18 +117,18 @@
If the bug leads to a tool linked to libvirt crash, then the best
is to provide a backtrace along with the scenario used to get the
crash, the simplest is to run the program under gdb, reproduce the
- steps leading to the crash and then issue a gdb "bt" command to
+ steps leading to the crash and then issue a gdb "bt -a" command to
get the stack trace, attach it to the bug. Note that for the
data to be really useful libvirt debug informations must be present
for example by installing libvirt debuginfo package on Fedora or
Red Hat Enterprise Linux (with debuginfo-install libvirt) prior
to running gdb.</p>
<p>
- It may also happen that the libvirt daemon itself crashes or get stuck,
+ It may also happen that the libvirt daemon itself crashes or gets stuck,
in the first case run it (as root) under gdb, and reproduce the sequence
leading to the crash, similary to a normal program provide the
"bt" backtrace information to where gdb will have stopped.<br/>
- But if libvirtd get stuck, for example seems to stop processing
+ But if libvirtd gets stuck, for example seems to stop processing
commands, try to attach to the faulty daemon and issue a gdb command
"thread apply all bt" to show all the threads backtraces, as in:</p>
<pre> # ps -o etime,pid `pgrep libvirt`
@@ -106,10 +142,5 @@
(gdb)
</pre>
- <p>
- If requesting a new feature attach any available patch to the ticket
- and also email the patch to the libvirt mailing list for discussion
- </p>
-
</body>
</html>
--
1.7.7.6
More information about the libvir-list
mailing list