The two done comments.

Maybe refer to https://bugs.freebsd.org/261349 when committing. Thanks.

Maybe refer to https://bugs.freebsd.org/261349 when committing. Thanks.

Maybe refer to https://bugs.freebsd.org/261349 when committing. Thanks.

I don't yet have a build of the OS that includes efiwake, but the parts of the (non-rendered) manual page that I can read look OK to me. Thanks.

I deleted this word in the previous set of suggestions. Maybe Phabricator did not recognise the deletion.

Editing /usr/src/.git/COMMIT_EDITMSG, if I un-comment the Author line will that be enough for proper attribution?

Is this still accepted as it was in 2019?

Was this review overcome by events?

• zfs-create(8): ZFS for swap: caution, grammar by grahamperrin · Pull Request #14756 · openzfs/zfs.

D26218 was closed with a commit, does there remain a need to review this D26207?

@carlavilla FYI

In D22088#483028, @ota_j.email.ne.jp wrote:

… Then, I'd like to update man swapon to discourage and mention zfs/zvol short coming.

For what it's worth, I would find a rule such as this useful without the rule being comprehensive, or perfect …

… no reviewers specified.

I would like to see it enabled.

https://github.com/grahamperrin/freebsd-doc/commit/aa4e597798e1dd8f3120c6a05484747b5daf3d91

For drive-by readers: the rationale for abandonment here was https://reviews.freebsd.org/D38999.

In D39612#904547, @bofh wrote:

… We don't have a STABLE with dot releases …

This is probably a conversation for elsewhere … I really want to change that part of the primer …

The link: macro prefix is not required when the target starts with a URL scheme like https:.

In D39569#903020, @bofh wrote:

… what do you suggest? …

There is link redundancy in other contexts, so please change the name of this rule; make it more specific.

Similarly, in the announcement (the first link in Liam's article):

Thanks, I have not yet tested diff 120428.

In D39602#901381, @salvadore wrote:

Sorry, but I had zero inspiration.

Toying with scopes:

In D39560#901295, @salvadore wrote:

… if line 110 is fixed, then vale reports line 89. When line 89 is fixed, it reports line 91 and so on. So, for some reason, vale applies the rule only once.

In D39560#901277, @salvadore wrote:

Have you tried switching from level: error to level: warning as suggested in the above comments?

In D39560#901262, @salvadore wrote:

… fixing in https://reviews.freebsd.org/D39567#change-bq5lJMuUrbA0.

In D39560#900625, @salvadore wrote:

I have tested it successfully on this quarter status reports. …

uefi(8): refer to loader.efi(8) instead of loader(8)

3. loader.efi loads and boots the kernel, as described in loader(8).

• https://github.com/freebsd/freebsd-doc/pull/164 is updated and closed
• https://bugs.freebsd.org/270338 is updated
• branch https://github.com/grahamperrin/freebsd-doc/tree/bug-270338 remains.

Fixed in GitHub, I think …

Sorry, I'll be unable to resolve the conflict at the command line (and please, no offers of help), can someone else do the honours with resolution and commit? Many thanks

Thanks, overlap with https://github.com/freebsd/freebsd-doc/commit/b8788e696d, I'll manually edit my branch in GitHub to match Allan's changes, then … deal with likely trailing whitespace errors (my habitual mistake) and push.

For now, can we get the warning in quickly? Then refine things.

https://github.com/freebsd/freebsd-doc/pull/164/commits/78fc0f2082493013b42df10c18435c4f65446b47

…

An example of a module that will not load following a simple forced upgrade of its package:

…

Thanks, and apologies for bumping.

Incidentally, why the Hell did my inline view of my comment disappear before submission?

For what it's worth, I'd refer to https://docs.asciidoctor.org/asciidoc/latest/syntax-quick-reference/#text-formatting instead of enlarging a primer that is already, to my eye, way too large to be thought of as a primer …

Side notes

https://github.com/freebsd/freebsd-doc/pull/164/commits/3ee9f64e3b14d700ae391fffef1f08308b52675a – @ceri's correction.