External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-07-06 09:55:46 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: point users to gitlab for issue tracking

Browse Source 
Currently we use the "Virtualization Tools" product in Red Hat Bugzilla
for issue tracking upstream. This changes to point people to GitLab for
issue tracking.

Note that Bugzilla still has plenty of bugs present against libvirt.
Triaging these to determine what is still valid will be a separate
exercise. Bugzilla will be locked to prevent creation of new issues
meanwhile.

Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This commit is contained in:
Daniel P. Berrangé 2020-04-09 14:40:47 +01:00
parent b157bf46c9
commit 91205f1a86
2 changed files with 16 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
docs/best-practices.rst
View File

@ -15,8 +15,9 @@ with minimal back-and-forth.
by any longer description of why your patch makes sense. If the
patch fixes a regression, and you know what commit introduced
the problem, mentioning that is useful. If the patch resolves a
bugzilla report, mentioning the URL of the bug number is
useful; but also summarize the issue rather than making all
upstream bug reported in GitLab, put "Fixes: #NNN" in the commit
message. For a downstream bug, mention the URL of the bug instead.
In both cases also summarize the issue rather than making all
readers follow the link. You can use 'git shortlog -30' to get
an idea of typical summary lines.

25
docs/bugs.html.in
View File

@ -19,7 +19,7 @@
<a href="securityprocess.html">security process</a> instead.
</p>
<h2><a id="bugzilla">Bug Tracking</a></h2>
<h2><a id="bugtracking">Bug Tracking</a></h2>
<p>
If you are using libvirt binaries from a Linux distribution
@ -30,22 +30,17 @@
<h2><a id="general">General libvirt bug reports</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.
Bugs in upstream libvirt code should be reported as issues in the
appropriate <a href="https://gitlab.com/libvirt">project on GitLab.</a>
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
the problem. However, not everybody in the community pays frequent
attention to issues, 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
@ -65,10 +60,16 @@
</p>
<ul>
<li><a href="http://bugzilla.redhat.com/buglist.cgi?component=libvirt&amp;product=Virtualization%20Tools">View libvirt tickets</a></li>
<li><a href="http://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Virtualization%20Tools&amp;component=libvirt">New libvirt ticket</a></li>
<li><a href="https://gitlab.com/libvirt/libvirt/-/issues">View libvirt.git tickets</a></li>
<li><a href="https://gitlab.com/libvirt/libvirt/-/issues/new">New libvirt.git ticket</a></li>
</ul>
<p>
Note bugs in language bindings and other sub-projects should be
reported to their corresponding git repository rather than the
main libvirt.git linked above.
</p>
<h2><a id="distribution">Linux Distribution specific bug reports</a></h2>
<ul>
<li>