all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: "Max Carrara" <m.carrara@proxmox.com>
To: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH docs 1/6] ceph: add anchors for use in troubleshooting section
Date: Tue, 04 Feb 2025 10:52:48 +0100	[thread overview]
Message-ID: <D7JKIHEE0XZW.1WGVRUD004T88@proxmox.com> (raw)
In-Reply-To: <D7JJVD5FQZMH.22W20LB84CWM7@proxmox.com>

On Tue Feb 4, 2025 at 10:22 AM CET, Alexander Zeidler wrote:
> On Mon Feb 3, 2025 at 5:19 PM CET, Max Carrara wrote:
> > On Mon Feb 3, 2025 at 3:27 PM CET, Alexander Zeidler wrote:
> >> Signed-off-by: Alexander Zeidler <a.zeidler@proxmox.com>
> >> ---
> >
> > Some high-level feedback (see comments inline and in patches otherwise):
> >
> > - The writing style is IMO quite clear and straightforward, nice work!
> Thank you for the review!
>
> >
> > - In patch 03, the "_disk_health_monitoring" anchor reference seems to
> >   break my build for some reason. Does this also happen on your end? The
> >   single-page docs ("pve-admin-guide.html") seem to build just fine
> >   otherwise.
> Same for me, I will fix it.
>
> >
> > - Regarding implicitly / auto-generated anchors, is it fine to break
> >   those in general or not? See my other comments inline here.
> >
> > - There are a few tiny style things I personally would correct, but if
> >   you disagree with them, feel free to leave them as they are.
> I will look into it! Using longer link texts sounds good!
>
> >
> > All in all this seems pretty solid; the stuff regarding the anchors
> > needs to be clarified first (whether it's okay to break auto-generated
> > ones & the one anchor that makes my build fail). Otherwise, pretty good!
> See my two comments below.
>
> >
> >>  pveceph.adoc | 8 ++++++++
> >>  1 file changed, 8 insertions(+)
> >>
> >> diff --git a/pveceph.adoc b/pveceph.adoc
> >> index da39e7f..93c2f8d 100644
> >> --- a/pveceph.adoc
> >> +++ b/pveceph.adoc
> >> @@ -82,6 +82,7 @@ and vocabulary
> >>  footnote:[Ceph glossary {cephdocs-url}/glossary].
> >>  
> >>  
> >> +[[pve_ceph_recommendation]]
> >>  Recommendations for a Healthy Ceph Cluster
> >>  ------------------------------------------
> >
> > AsciiDoc automatically generated an anchor for the heading above
> > already, and it's "_recommendations_for_a_healthy_ceph_cluster"
> > apparently. So, there's no need to provide one here explicitly, since it
> > already exists; it also might break old links that refer to the
> > documentation.
> For this I searched our forum before, it shows 12 results, the heading
> was only added about a year ago. But apart from this specific anchor,
> IMHO it can be okay to break such links in certain cases:
>
> * The main reasons for not using the auto generated ones are, that those
>   are not stable (in case of changing the title) and can also be very
>   long when using it with xref:...[...]. Such lines get even longer (and
>   an awkward combined name) when using it as a prefix for sub sections
>   (as often done).
> * Since with the break there might have been added new or updated
>   information in those chapters/sections, old forum posts may no longer
>   be accurate anyway.
> * In the Ceph chapter for example, we have been using the explicit
>   "pve_ceph_" or "pveceph_" for years, so IMHO it should (almost
>   always?) be added with adding a new section.
>
> >
> > Though, perhaps in a separate series, you could look for all implicitly
> > defined anchors and set them explicitly..? Not sure if that's something
> > we want, though.
> This would break a lot of links at the same time, so far I am not aware
> about a notable benefit.
>

I agree with all of your points made here; so, all in all, great work!
Ping me when you shoot out v2, then I'll have one last look. :)



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


  reply	other threads:[~2025-02-04  9:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-03 14:27 Alexander Zeidler
2025-02-03 14:27 ` [pve-devel] [PATCH docs 2/6] ceph: correct heading capitalization Alexander Zeidler
2025-02-03 14:27 ` [pve-devel] [PATCH docs 3/6] ceph: troubleshooting: revise and add frequently needed information Alexander Zeidler
2025-02-03 16:19   ` Max Carrara
2025-02-03 14:27 ` [pve-devel] [PATCH docs 4/6] ceph: osd: revise and expand the section "Destroy OSDs" Alexander Zeidler
2025-02-03 16:19   ` Max Carrara
2025-02-03 14:28 ` [pve-devel] [PATCH docs 5/6] ceph: maintenance: revise and expand section "Replace OSDs" Alexander Zeidler
2025-02-03 14:28 ` [pve-devel] [PATCH docs 6/6] pvecm: remove node: mention Ceph and its steps for safe removal Alexander Zeidler
2025-02-03 16:19 ` [pve-devel] [PATCH docs 1/6] ceph: add anchors for use in troubleshooting section Max Carrara
2025-02-04  9:22   ` Alexander Zeidler
2025-02-04  9:52     ` Max Carrara [this message]
2025-02-05 10:10       ` Alexander Zeidler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D7JKIHEE0XZW.1WGVRUD004T88@proxmox.com \
    --to=m.carrara@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal