On a Thursday in 2020, Daniel P. Berrangé wrote:
> 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.
>
> Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
> ---
> docs/best-practices.rst | 5 +++--
> docs/bugs.html.in | 27 ++++++++++++++-------------
> 2 files changed, 17 insertions(+), 15 deletions(-)
>
> diff --git a/docs/best-practices.rst b/docs/best-practices.rst
> index 7c48ff10be..4a28b03b65 100644
> --- a/docs/best-practices.rst
> +++ b/docs/best-practices.rst
> @@ -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.
>
> diff --git a/docs/bugs.html.in b/docs/bugs.html.in
> index 5534223384..c717fa813d 100644
> --- a/docs/bugs.html.in
> +++ b/docs/bugs.html.in
> @@ -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="http://gitlab.com/libvirt">GitLab
project.</a>
* please use https
* GitLab project makes it sound to me like "a project by GitLab"
<a
href="https://gitlab.com/libvirt">project on GitLab</a>.