[libvirt PATCH 1/6] docs: point users to gitlab for issue tracking

Daniel P. Berrangé berrange at redhat.com
Thu Apr 9 15:35:11 UTC 2020


On Thu, Apr 09, 2020 at 04:33:04PM +0200, Ján Tomko wrote:
> 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 at 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>.

Yes, that's nicer.



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




More information about the libvir-list mailing list