Applying both ``code`` and **bold** formatting doesn't have the intended
outcome, instead Sphinx emits the backticks into the HTML.

Use only **bold** formatting to fix the HTML output.

Signed-off-by: J. Neuschäfer <j.neuschaefer@9elements.com>
---
I'm fine with either solution, keeping the bold or code formatting, and I'll
switch to the other if requested. They just don't mix well.
---
 docs/devel/code-provenance.rst | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/docs/devel/code-provenance.rst b/docs/devel/code-provenance.rst
index 4e6a9afe0d672c544c069447a9978baa0b4a6212..65b8f232a08f6bc903c77fd0b1f7a5adad9fbe5d 100644
--- a/docs/devel/code-provenance.rst
+++ b/docs/devel/code-provenance.rst
@@ -99,13 +99,13 @@ Other commit tags
 While the ``Signed-off-by`` tag is mandatory, there are a number of other tags
 that are commonly used during QEMU development:
 
- * **``Reviewed-by``**: when a QEMU community member reviews a patch on the
+ * **Reviewed-by**: when a QEMU community member reviews a patch on the
    mailing list, if they consider the patch acceptable, they should send an
    email reply containing a ``Reviewed-by`` tag. Subsystem maintainers who
    review a patch should add this even if they are also adding their
    ``Signed-off-by`` to the same commit.
 
- * **``Acked-by``**: when a QEMU subsystem maintainer approves a patch that
+ * **Acked-by**: when a QEMU subsystem maintainer approves a patch that
    touches their subsystem, but intends to allow a different maintainer to
    queue it and send a pull request, they would send a mail containing a
    ``Acked-by`` tag. Where a patch touches multiple subsystems, ``Acked-by``
@@ -113,18 +113,18 @@ that are commonly used during QEMU development:
    maintainer wants to indicate they have done a full review they should use
    a ``Reviewed-by`` tag.
 
- * **``Tested-by``**: when a QEMU community member has functionally tested the
+ * **Tested-by**: when a QEMU community member has functionally tested the
    behaviour of the patch in some manner, they should send an email reply
    containing a ``Tested-by`` tag.
 
- * **``Reported-by``**: when a QEMU community member reports a problem via the
+ * **Reported-by**: when a QEMU community member reports a problem via the
    mailing list, or some other informal channel that is not the issue tracker,
    it is good practice to credit them by including a ``Reported-by`` tag on
    any patch fixing the issue. When the problem is reported via the GitLab
    issue tracker, however, it is sufficient to just include a link to the
    issue.
 
- * **``Suggested-by``**: when a reviewer or other 3rd party makes non-trivial
+ * **Suggested-by**: when a reviewer or other 3rd party makes non-trivial
    suggestions for how to change a patch, it is good practice to credit them
    by including a ``Suggested-by`` tag.
 

---
base-commit: 6d17fd91f6cf88df5cb2205e578640d72605cc43
change-id: 20260520-prov-73c69e4e979c

Best regards,
-- 
J. Neuschäfer <j.neuschaefer@9elements.com>

On 5/20/2026 4:25 AM, J. Neuschäfer wrote:
> Applying both ``code`` and **bold** formatting doesn't have the intended
> outcome, instead Sphinx emits the backticks into the HTML.
> 
> Use only **bold** formatting to fix the HTML output.
> 
> Signed-off-by: J. Neuschäfer <j.neuschaefer@9elements.com>
> ---
> I'm fine with either solution, keeping the bold or code formatting, and I'll
> switch to the other if requested. They just don't mix well.
> ---
>  docs/devel/code-provenance.rst | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/docs/devel/code-provenance.rst b/docs/devel/code-provenance.rst
> index 4e6a9afe0d672c544c069447a9978baa0b4a6212..65b8f232a08f6bc903c77fd0b1f7a5adad9fbe5d 100644
> --- a/docs/devel/code-provenance.rst
> +++ b/docs/devel/code-provenance.rst
> @@ -99,13 +99,13 @@ Other commit tags
>  While the ``Signed-off-by`` tag is mandatory, there are a number of other tags
>  that are commonly used during QEMU development:
>  
> - * **``Reviewed-by``**: when a QEMU community member reviews a patch on the
> + * **Reviewed-by**: when a QEMU community member reviews a patch on the
>     mailing list, if they consider the patch acceptable, they should send an
>     email reply containing a ``Reviewed-by`` tag. Subsystem maintainers who
>     review a patch should add this even if they are also adding their
>     ``Signed-off-by`` to the same commit.
>  
> - * **``Acked-by``**: when a QEMU subsystem maintainer approves a patch that
> + * **Acked-by**: when a QEMU subsystem maintainer approves a patch that
>     touches their subsystem, but intends to allow a different maintainer to
>     queue it and send a pull request, they would send a mail containing a
>     ``Acked-by`` tag. Where a patch touches multiple subsystems, ``Acked-by``
> @@ -113,18 +113,18 @@ that are commonly used during QEMU development:
>     maintainer wants to indicate they have done a full review they should use
>     a ``Reviewed-by`` tag.
>  
> - * **``Tested-by``**: when a QEMU community member has functionally tested the
> + * **Tested-by**: when a QEMU community member has functionally tested the
>     behaviour of the patch in some manner, they should send an email reply
>     containing a ``Tested-by`` tag.
>  
> - * **``Reported-by``**: when a QEMU community member reports a problem via the
> + * **Reported-by**: when a QEMU community member reports a problem via the
>     mailing list, or some other informal channel that is not the issue tracker,
>     it is good practice to credit them by including a ``Reported-by`` tag on
>     any patch fixing the issue. When the problem is reported via the GitLab
>     issue tracker, however, it is sufficient to just include a link to the
>     issue.
>  
> - * **``Suggested-by``**: when a reviewer or other 3rd party makes non-trivial
> + * **Suggested-by**: when a reviewer or other 3rd party makes non-trivial
>     suggestions for how to change a patch, it is good practice to credit them
>     by including a ``Suggested-by`` tag.
>  
> 
> ---
> base-commit: 6d17fd91f6cf88df5cb2205e578640d72605cc43
> change-id: 20260520-prov-73c69e4e979c
> 
> Best regards,

This was merged into master (cbf877d67a812be17a9ce404a589e1bdf722c1f6).
Thank you for your contribution!

Regards,
Pierrick

On 5/20/2026 4:25 AM, J. Neuschäfer wrote:
> Applying both ``code`` and **bold** formatting doesn't have the intended
> outcome, instead Sphinx emits the backticks into the HTML.
> 
> Use only **bold** formatting to fix the HTML output.
> 
> Signed-off-by: J. Neuschäfer <j.neuschaefer@9elements.com>
> ---
> I'm fine with either solution, keeping the bold or code formatting, and I'll
> switch to the other if requested. They just don't mix well.
> ---
>  docs/devel/code-provenance.rst | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 

I'm good with this solution too.
I'll pull this through docs subsystem.

Reviewed-by: Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com>

Regards,
Pierrick

On Wed, May 20, 2026 at 01:25:49PM +0200, J. Neuschäfer wrote:
> Applying both ``code`` and **bold** formatting doesn't have the intended
> outcome, instead Sphinx emits the backticks into the HTML.
> 
> Use only **bold** formatting to fix the HTML output.
> 
> Signed-off-by: J. Neuschäfer <j.neuschaefer@9elements.com>
> ---
> I'm fine with either solution, keeping the bold or code formatting, and I'll
> switch to the other if requested. They just don't mix well.

Bold is probably the least worst option here, as it helps legibility
of the doc more IMHO.

> ---
>  docs/devel/code-provenance.rst | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


> 
> diff --git a/docs/devel/code-provenance.rst b/docs/devel/code-provenance.rst
> index 4e6a9afe0d672c544c069447a9978baa0b4a6212..65b8f232a08f6bc903c77fd0b1f7a5adad9fbe5d 100644
> --- a/docs/devel/code-provenance.rst
> +++ b/docs/devel/code-provenance.rst
> @@ -99,13 +99,13 @@ Other commit tags
>  While the ``Signed-off-by`` tag is mandatory, there are a number of other tags
>  that are commonly used during QEMU development:
>  
> - * **``Reviewed-by``**: when a QEMU community member reviews a patch on the
> + * **Reviewed-by**: when a QEMU community member reviews a patch on the
>     mailing list, if they consider the patch acceptable, they should send an
>     email reply containing a ``Reviewed-by`` tag. Subsystem maintainers who
>     review a patch should add this even if they are also adding their
>     ``Signed-off-by`` to the same commit.
>  
> - * **``Acked-by``**: when a QEMU subsystem maintainer approves a patch that
> + * **Acked-by**: when a QEMU subsystem maintainer approves a patch that
>     touches their subsystem, but intends to allow a different maintainer to
>     queue it and send a pull request, they would send a mail containing a
>     ``Acked-by`` tag. Where a patch touches multiple subsystems, ``Acked-by``
> @@ -113,18 +113,18 @@ that are commonly used during QEMU development:
>     maintainer wants to indicate they have done a full review they should use
>     a ``Reviewed-by`` tag.
>  
> - * **``Tested-by``**: when a QEMU community member has functionally tested the
> + * **Tested-by**: when a QEMU community member has functionally tested the
>     behaviour of the patch in some manner, they should send an email reply
>     containing a ``Tested-by`` tag.
>  
> - * **``Reported-by``**: when a QEMU community member reports a problem via the
> + * **Reported-by**: when a QEMU community member reports a problem via the
>     mailing list, or some other informal channel that is not the issue tracker,
>     it is good practice to credit them by including a ``Reported-by`` tag on
>     any patch fixing the issue. When the problem is reported via the GitLab
>     issue tracker, however, it is sufficient to just include a link to the
>     issue.
>  
> - * **``Suggested-by``**: when a reviewer or other 3rd party makes non-trivial
> + * **Suggested-by**: when a reviewer or other 3rd party makes non-trivial
>     suggestions for how to change a patch, it is good practice to credit them
>     by including a ``Suggested-by`` tag.
>  
> 
> ---
> base-commit: 6d17fd91f6cf88df5cb2205e578640d72605cc43
> change-id: 20260520-prov-73c69e4e979c
> 
> Best regards,
> -- 
> J. Neuschäfer <j.neuschaefer@9elements.com>
> 
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|