Cool! Just some doc nits from me.

Sorry for all the questions, just trying to figure out if I can clarify the docs somehow, or maybe even if it makes sense just to fix one of the other options, because we have a great deal of options which sound like they should do this already.

Adding Pierre because he's doing a lot of installer work the past few years, and manpages because this involves a manual page change (and then I can accept it limited to the scope of my review).

I can't really help on the Lua, but here's some manual page feedback. Unrelated, the cannonical name of .Sh ENVIRONMENT VARIABLES is just .Sh ENVIRONMENT.

we have a customer that wants nothing printed on the screen

Should it be "autoboot_show" like "autoboot_delay"?

How does this interact with "autoboot_delay"?

Ping

@jimb, check out how I edited the commit message title. The link I provided earlier explains the finer points of how to write this line, but basically, what is changing needs to come first, and notice the difference between dhclient.conf and dhclient.conf.5. The former could be assumed to be the default configuration itself, the second is the manual. Then comes a colon, then a space and then the explanation of what is being changed about it (capitalize the beginning).

Looks perfect!

That makes sense! If you "Edit Revision" from top right corner of the webapp, you could put:

In this example, the comparison operator is "contains" which does a substring match, not a regular expression match.

Where I put the angle brackets, and then that becomes the commit message body. After, you can verify with (in a new branch) git arc patch -c D49461 && git show.

for format/typo changes, I don't bump the date.

Even further, the links to the organizations listed in ipfw are dead.

Thank you, this is a perfect example for what I am trying to say.

I think you made another commit instead of amending the prior commit, and then uploaded that, so the patch is actually against your previous patch instead of against main, so it will not apply. To fix this, you can use 'git log' to verify that we have just two or something commits on the stack, and then use git rebase -i HEAD~3 to squash them down into one commit, then use git-arc to update the patch again.

Following our discussion today about patch movement, @michaelo could commit this or I'd need @carlavilla or @mhorne to approve it. For me to do it, I need a better commit message. Unfortunately afaik you need to use the webapp to do this.

Hey Jim, following our discussion today, what's holding up this one is:

1. The commit body needs an explanation why
2. Then I need someone else who is familiar with ipfw to verify the syntax
3. Then I need mhorne or carlavilla to approve it

Then I would be able to commit it.

Add "package" to firmware explanation, thanks @patmaddox

Perfect, I'll have my FreeBSD/ipv6 expert review this when they get a chance. Thanks again.

Would you please put all of these changes to this section in one review, and close the others? Thanks for working on the handbook!

Can you put this in with your other change to this section?

Lexi, can you confirm?

s/bhyve(8)/bhyve(8) virtual machines./

Typo

BSS mode > station mode

Fix spelling typo for real this time, thanks Pat!

The problem is that the line ends up about 100 characters long, using what the Committer's Guide recommends. Is that ok?

I do really love putting the commit that the work depends on in "Fixes: " instead of the introductory sentence of the commit message. It makes me feel like the the sentence is clean and just explaining for me, and very predictable to track the tree of events related to the commit.

This looks sharp! The first sentence explains everything. Terse, informative, perfect. Personally, I do prefer that we keep metadata like the commit hash in commit trailers such as "Fixes:" and do the first sentence of commit messages the same way.

Hey Tom! It's always very anxious about the relationship when I have disagreements. Even though I'm obligated to make my case, I really appreciate your review!

fix another syntax typo

Correct syntax typo (missing end of list).

Add SYSCTL VARIABLES, modeled off mtw.

Maybe we don't even have to bloat it at all and could say:
"Each argument must be an existing Phabricator user or #group."

Should I be commenting this out instead?

I'm not sure what I didn't do right, or if something's hurt in our cluster, but I committed this as https://cgit.freebsd.org/doc/commit/?id=f8006b944cae79a909bc9d647ede5f5d8b7d7175

Realized there should be a Pp in HARDWARE.

Intel actually calls these adapters "Intel Wi-Fi 6" series.

Mention no crypto offload yet in CAVEATS.
Does this driver also not yet support other offloads?
I think it would be really good to note them here.

Oops, just had an even better idea:
"Specify a file-creation timestamp using the same syntax as"
Sorry for the noise.

Remove one of the newlines in description,
I decided I don't really like it.

Attempt to fix iwx.4 Makefile based on sys/modules/Makefile