I think it's time we land this, as I've been recently reminded just how nice it'd be to have this. :)

Shouldn't you also be changing things for 12.3-RELEASE?

Seems fine, but I hope you're checking with nc -z from freefall.f.o if they're working. ;)

That's fair - perhaps link to it instead?

The handbook is as much, if not more, for -RELEASE than it is for -CURRENT - so I'm of the belief that something is in the process of being deprecated when it has been removed in -CURRENT and until it's final existence in the last -RELEASE is end-of-life'd.

I don't think we should be removing references to these mailing lists as I know for a fact that I'm not the only one that uses them or might need them in the future.

Have you contacted the hostmaster for the domain, before removing it?

Looks good to me, but make sure you build- and view-test it in a browser before pushing, please.

Manual page looks good.

After a40cf4175c901 that you implemented last year, is a privileged prompt necessary, or would it be better to recommend using unprivileged chroot after toggling the sysctl OID?

I'm gonna go ahead and approve this, and leave the choice of macro up to you prior to when you commit and push. :)

I have a little bit of mdoc(7) feedback.

In D33738#765425, @pauamma_gundo.com wrote:

With my final 2 nitpicks, I think it is. Approve at will once they're addressed.

mdoc(7) changes look good to me, don't really have opinions on whether it should be the default but it seems like a good idea from a brief look at what termios(4) is.

Is this ready for approval so it can land? It looks to me like it is.

Looks good to me.

In D33738#764635, @trasz wrote:

Thanks! I wonder, should perhaps igor(1) warn about this, or am I using the wrong tool?

I just noticed one other thing:
The document goes from using one line per sentence to splitting sentences in the middle, which as far as I know causes problems.

In D33677#764161, @jo_bruelltuete.com wrote:

thanks for looking at the patch!

adding a note to the bugs section is prob the most appropriate as we are directing ppl to check out the vendor driver in case they have problems with the in-source one.

You know, I think you're right that it looks better. Do your thing!

Only spotted one minor thing which I think is just an honest mistake.

Maybe it's worth mentioning that (R) gets rendered by AsciiDoctor as ® as is both outlined here and can be spotted on the rendered output of the existing page.

mdoc formatting looks good to me too, but maybe someone else wants to chime in on the code?

Firstly, please see the Phabricator wiki article for information on how to create a full-context diff - it makes it easier for us to make in-line suggestions.

Looks good to me too.

This looks good to me, and I'm sure bcr approves of you remembering to bump .Dd too ;)

In D33394#755020, @0mp wrote:

Perhaps it would be nice to mention that sometimes the best idea is to set -width to the longest item "of reasonable length" (less than 10 characters?).

I think it's better to recommend nvidia-modeset, since it should let Xorg use the modesetting driver that's being used for i915kms, radeonkms, and amdgpu.

LGTM. :)

LGTM. :)

Is something going wrong with some tooling? Because it looks like your diffs are being applied as comments, not to the revision itself?

Would it be an idea to refer to this manual page from boot(9), boot(8), and/or some other relevant manual pages - to make it easier to discover?

LGTM. :)

This landed with commit bd6dce978c1a, but I forgot to add the differential revision tag.

I think it'd be nice to get all other functions marked up properly too, unless they're part of display blocks (Bd Ed macros in mdoc).

Address feedback by PauAmma

The proper way to solve this would be to use /usr/bin/env $BINARY because if that doesn't work, the OS that the tree is being built on isn't POSIX-compliant at all.

This looks good to me.

There's only one minor nit, but otherwise it looks good to me.

Are there other places where -(j|J) -1 is used to list all jails, instead of simply doing -(j|J)?

Also, to channel bcr:
Remember to bump .Dd :)

Try to address feedback by a.wolk

I don't think enough context was included, because I'm still seeing "Context not available" - any chance you can use arcanist from ports/packages (as described on the wiki article I linked earlier) or src/tools/tools/git/git-arc.sh (which can be installed by doing make -C /usr/src/tools/tools/git/ install (which requires arcanist, git, and textproc/jq?

Could you please update the diff to one made using the instructions on the Phabricator wiki article?

This is only true if you use format-patch?

I believe you need to use git-am(1) to get the metadata (author, timestamps, et cetera) applied.

Here's a few things I noticed.

For the record, the mdoc looks good to me now.
I can't speak to the code.

In D32269#728549, @rew wrote:

Which item macros are you referring to?

Did the item macros disappear by choice? Just checking.

Just a minor nit, otherwise it looks good to me.

I noticed that there are several places where a phrase is entirely or almost entirely repeated, and in my experience that's the sort of thing that makes it hard to scan through a manual page quickly - so I think it might be a good idea to rephrase things a bit.
Ideally I'd also really like to see the words include and exclude be used, as they're the kind of keywords that one would look for when dealing with this kind of thing.

LGTM. :)

I've given it another once-over, and am pretty happy with it, so unless anyone else has any interjections, I say it's good to go.

In D31707#715576, @bcr wrote:

That's right. My understanding is that everything is a dataset unless it was created by "zfs create -V ...", which for me is a volume (and used in this way). As you said, it may change or even blur some more with future changes. My idea is to use them consistently, for example mention datasets everywhere when it comes to ZFS features. When involving mountpoints, I'd refer to file systems, like this: "Mount the dataset as a file system into the directory tree." That way, we use it only when necessary, but keep the dataset syntax. Same when it involves volumes.

In D31707#715576, @bcr wrote:

Maybe one more reason to use dataset more to avoid this ambiguity? ;-)

These are a few things I spotted, but I'm not sure I caught everything and I'm on the wrong side of entirely sober. :)

Can you switch this diff to one with context? It makes it easier to make suggestions. :)

Just some minor nits.

I clearly shouldn't review things when I'm tired. Sorry. :(

Seems like an excellent idea.

I don't really have time for this right now, so someone else can go ahead and commit it once it's been accepted.

In D30589#687207, @imp wrote:

I don't like the passive voice, due to forced conditioning in high school Freshman English.... however, I know that's the style here...

The documentation team prefers to avoid use of 'you' in the handbook (and any other documentation).

Have you tested with textproc/igor and mandoc -T lint?

In D30336#681311, @a.wolk_fudosecurity.com wrote:

Updated the raw diff using the git show -U999999 <commit-hash> > change.diff method. Hope that helps! :)

Address feedback by 0mp

The current diff you've uploaded lacks context for Phabricator to tell which part of the file it applies to (I don't know why Phabricator can't always figure out the context), which is why the "Context not available" message appears.

Yes, it would be good to have a documented method of checking the protected flag, so go ahead and add that.

Fix cross reference