Manpage LGTM, and I like that you folded it into the revision, no comment on the anything else.

Sorry I'm late, thanks for your patience.

Ping

In D58495#1342753, @ivy wrote:

In D58495#1342419, @ziaee wrote:

Thanks for tagging me! We just mail the patch to tech@mandoc.bsd.lv. I can do it if you don't want to.

i can do that as long as i don't need to be subscribed to the list to post to it. do they prefer git send-email format?

Yes, please MFC after 3 days.

Thanks for tagging me! We just mail the patch to tech@mandoc.bsd.lv. I can do it if you don't want to.

So we've been trying to standardize this language, here's the draft: https://reviews.freebsd.org/D57690

Wow this is so exciting! I don't have this hardware to test but I've been following the manpage for some time! Congrats!

Hey bz! Thanks for tagging me! Accepted with or without my suggestions.

Please make sure to MFC this.

Hey Artem, thanks for the patch.

Thanks for the quick reviews team.

In D58329#1338905, @temcbun_gmail.com wrote:

Document descriptions should not have crossreferences especially, but really any child macros.
Manpage compiler upstream has said (quite strongly and hilariously actually) it's wrong.

But where exactly does it say this?

I have not reviewed this because all I know about colors is how to turn them off, drives me crazy. Maybe... @dteske might know?

editorial nits

*dances*

In D58186#1338416, @ivy wrote:

Relnotes: yes (although i doubt many people are using this, i do think we should highlight package moves like this).

Exciting! Firewire is an important interface for musical and scientific equipment!

Thank you both, I think this is a great new feature for the sh manual and I am so excited to land this now!

Thanks @emaste! I hope you had a good AFK!

I was thinking along the lines of the latter, that this doc is strictly for upgrading existing systems to 15.1-RELEASE.

But, we consistently use the terms AArch64 and AMD64, so I'd like to just use that, since they would have gotten far enough to have a system that they are upgrading if they didn't know that. Even the downloads page only says those terms.

"AArch64 systems always use the UEFI boot loader.
To determine which boot loader to update on AMD64 systems, run the following command:"

Thanks for helping with it. Can I land it instead? This is part of GCE C4A turnup.

ping

ping

Oops, I did not add back the check. Thanks @bnovkov!

What can I do to make this acceptable to you? I feel very strongly that documenting that this is not implemented (if it is truly not implemented, which it seems to be) will save people time and inform purchasing decisions. We document missing hardware features widely in our manuals, and mdoc(7) recommends it (limitations):

I committed my diff switching branch names to macros. However there are other improvements in this patch that could be rebased.

Oh I see

LGTM with the highlighted attribution fix. Thanks for writing this!

Please remember to set the author on this one. git commit --amend --author="Jim Brown <jpb@jimby.name>". He stopped contributing because we were not giving him enough attention.

I support this since we do not even have doc on uefisign yet, nor have built any tooling around it. This is a win for consistency and reduced operator mental load. We also need to update these files:

$ cd src; git grep uefisign
etc/mtree/BSD.usr.dist:            uefisign
share/man/man8/uefi.8:.Xr uefisign 8
targets/pseudo/userland/Makefile.depend:        usr.sbin/uefisign \

\o/

In D58145#1333433, @nick_spun.io wrote:

(This is the base of the diff stack but got committed last because I copied the wrong commit hash when I was initially using git-arc)

Thanks for doing this! Can you also put a Fixes: commit message trailer so that we know when/how far back to backport this change.

Ooh I love this!

@kfv_kfv.io are you okay with using the abridged license form shown in style.9 and the freebsd license guide?

Would you also add a Relnotes: yes? I'd like to list all new manpages in the manpage section of the release notes.

In D57720#1331295, @temcbun_gmail.com wrote:

@ziaee Could you please MFC this commit (I see the commit message says it is to be MFCed after 3 days, but it's still not).

In D57931#1331014, @markj wrote:

I don't understand why this man page (or any section 9 page) needs to be mentioned in the release notes. It's just documenting some internals, nothing that anyone other than a kernel developer might care about...

Can you also Relnotes: yes?

I think when this is ready we should consider asking Pawel to review it.

For the PR make sure to use a commit message trailer "PR: 296419" so that it gets copied to the bug.

Oops

Should we relnotes yes?

In D58001#1330236, @bcr wrote:

We can't make changes to past release notes once they are published. They become part of the release hash and would change in a number of places that reference them (even if they contain typos).

Do you see any problems with them?

In D57999#1330065, @carlavilla wrote:

In D57999#1330057, @ziaee wrote:

Dude you rock! Aside from dev-model, all the changes LGTM.

if the macro is broken, I need to fix it. But I created this macros coz we have these scenarios:

• Online website (freebsd.org, docs.freebsd.org)
• Offline website
• PDFs

Dude you rock! Aside from dev-model, all the changes LGTM.

Thank you so much, I've tried various things and was unable to get to the bottom of this myself!

I think this would be great for a Relnotes: yes!

Thanks! I didn't bump the foundation copyright because I do not believe that I can do that unless under contract by them. I also alphabetized them.

Nothing from my end!

Thank you!

This never got committed, but eventually I was frustrated with reviewing PRs to bump release names and branches and spent the last few releases building out macros to do this. I have a draft here: https://reviews.freebsd.org/D57937, and you can see it in practice on the bsdinstall or jails chapters of the handbook. The macros are in doc/shared/releases.adoc and look like this:

Editorial looks good from manpages but I'd wait for someone who understands sbintime to review also. Thanks for writing this!

rework as discussed