do we have some kind of unified agreement that we're to accept PRs at all from GitHub from portmgr or people involved with ports?

In D47169#1113528, @diizzy wrote:

Actually this is incorrect, they NEED to be submitted on bugzilla for timeouts etc to apply

Do I have to bump the date on this one? Even though these are consequential typos, it isn't new content.

LGTM from manpages!

Great-grandmaster mckuscik,
Would you be willing to put vfs.ffs.prttimechgs in ffs(4) in this commit?
Huge fan of your work, and setting a good example of passion for next generations.
Sincerely,
Alex

No, I don't understand exactly what it does, but if the commit changes too much, git arc can't update it. You can apply it with git-arc.sh patch D48693.

Thanks! That's how I create them, but this one changed too much for git-arc.sh update HEAD.

Oops, I forgot to make the patch with -U9999 like bz taught me.
That, is an excellent example which I think is very appropriate to put in development(7).

Here's what I've got so far. I don't have any working non-amd64 devices to test many of these options on.

The description says build examples are in build(7) and release(7).
I think build(7) is a very sensible place for them, and I would like to
move this entire section there.

I'm not wrapping at 50. I wrap at 72 for compatiblity with the bsd text editor, vi, on the standard bsd console (80). The reason I wrap them a little before 72 is break them in the least awkward place grammatically.

Honestly, IMHO what would be best is Er=$actual_returned_number, but mandoc isn't written that way. The workflow for Er is actually purely imagined for me at this point since it doesn't exist yet for anything I've checked, which is normally completely unacceptable, but my rationale is that confirming to the standard will create allowance for the workflow.

A new document description and easier grammar was contributed by jhb!

alphabetize the options, except leaving --vm= first since it is always
first.

Use Er to markup error constants according to mdoc(7), and use
Dv to markup the exit numbers to enable apropos Dv=64.

That sounds reasonable. Thanks!

s/single kernel module/single loadable kernel module/ to differentiate
from modules in /boot/kernel/kernel.

Apply christos clarification.

Clean up document description and devfs_lookup.
The document description was broken on apropos due to macros,
and make devfs lowercase. The devfs_lookup was changed from
a non existent xref to a function.

Copy, thanks!

That's so exciting! Unfortunately, I have already failed at the very first step, I didn't fix the approved trailed in the commit log.

Revert attempt to sort contrib-comitters after realizing the doc said
sorted by last name. It is not sorted by last name.

Thanks! This is great info. I'll reflect on proper wording to reflect that it's designed to work on potentially unknown hardware.

Revert s/Dv/Sy/g, I did that to align with sysexits(3), however this was
a mistake as I think apropos Dv=EX_USAGE is an outstanding workflow. I
now believe that error messages should always be Dv.

Sorry, I forgot about moving filesystem manpages for freebsd 15!

Maybe helpful additional context:
Netbsd manpage says "Modifies the -l and -s options, causing the sizes to be reported in bytes displayed in a human readable format.".
Illumos manpage says "All sizes are scaled to a human readable format, for example, 14K, 234M, 2.7G, or 3.0T. Scaling is done by repetitively dividing by 1024. The last --si or -h option determines the divisor used."

Maybe "Show the file size in bytes with the following unit suffixes"?

bump date

Yes, style.mdoc(5) says "in case the longest item is too long and hurts readability, the reccomendattion is to set the -width argument to indent". I wasn't sure how to put that in the msg.

I don't know if this syntax is acceptable for referencing the src commit?

update to remove from release hw notes for 14.[0-2]

Thank you, I will fix them.

I don't see any leftover references to twe(4) using man -K "twe 4" "twe \(4" in the rest of the manual either.

Thank you for including me! When this passes I can remove it from the HW relnotes: https://reviews.freebsd.org/D48405.

I sure wish I could sneak the search word comment in here somewhere, but I was unable to figure out anything that seemed reasonable for the style of this doc.

Humble ping? I feel it's time for me to get started on 13.5 hw notes.

The manpage changes look great to me!

I'm so excited to test this driver this weekend! Thank you so much for submitting this! All of the suggestions I made are to bring it into alignment with the rest of the freebsd manual and are specified in the manual page style guide, style.mdoc(5). Sorry I'm so late.

I like total 131M with -h.