Yeah, let's hold off on celebrating the 30th anniversary until it actually happens, shall we? :)

I'll get this committed and pushed too, since it's such a trivial little fix.

Accepting as docs to avoid the confusion over misclick.

In D33073#779221, @fel1x.mintchoco.development_gmail.com wrote:

After you commit this, can you close these related bugzillas? 1 2

I think my suggestion is generic enough to give an indication of the amount of code used, without making it appear like a big portion of the code is taken from FreeBSD (which is a pretty common myth).

I'll accept as docs and wait for releng, then I'll commit once it's been accepted by them.

To add to what I said before, they've gotten pretty good at publishing what they include, if you can make head or tails of their snapshot release style.

I'm not sure I like this change, because without mentioning Mac OS X/macOS (the latter of which should probably be used), there's a lot more information to cover about the links between macOS and the Apple OSS distribution collection which includes XNU (where parts of the code enumerated here come from FreeBSD, because they originally came from BSD out of CSRG), along with the userland and the toolchain, libraries - and it's really not the FreeBSDs responsibility to keep track of all of that.

In D33073#778803, @fel1x.mintchoco.development_gmail.com wrote:

My name is 'Minsoo Choo', and email is 'fel1x.mintchoco.development@gmail.com'.
And I have a question. Can I change my email in my previous commits if I change my email address for development?(I'm considering to use ProtonMail)

While waiting for @releng to approve this, I'd like to know what you'd like to have listed as the author?
Usually it's in the form of git commit --author "Givenname Familyname <user AT example.org>".

Manual page change looks good to me.

What about changes to src/share/man/man5/ctf.5?

Looks good to me :)

I think this is ready to land now? So far as I can see everything's been addressed and a one-over didn't make anything else stand out.

Please run igor and mandoc -Tlint on the manual page - because among other things that they check for, I see that .Dd isn't bumped.

Looks good to me, though the summary (and thereby, the commit) should be "there's times". :)

Other than the nit and the question of when it should be pushed, this change looks good to me.

I think this is ready to go now?

OK from manpages then. :)

Have you run mandoc -Tlint and igor on the manual page?

mandoc -Tlint shows a few nits that I'd like to see corrected before this is committed.

mdoc changes look good to me

I made some comments here - but it looks to me like both my comments have or will be addressed shortly?

Manual page changes look good to me, can't comment on the code.

In D34099#771267, @pauamma_gundo.com wrote:

ObMeta; I can't make edit suggestions on this review as the button is missing from inline comments for some reason.

I'd also encourage you to run mandoc -Tlint, as you're missing some cross-references.

Here's a few things I noticed.

Seems like everything's been addressed, so let's get this committed.

In D34004#770198, @trasz wrote:

Yeah, I'll submit the other changes for separate reviews.

Regarding "Installer images" - problem is, not all of those are installer images. I wonder if I should perhaps split off SD card images like it was before...

Also: is there a way to make cells vertically aligned up, as opposed to vertically centered, as it is now? The example from AsciiDoc didn't seem to work for some reason.

mdoc looks good, you can fix the nit Pau Amma pointed out

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.