Did you mean to add some reviewers for this too? :)
Looks like @rwatson might have some thoughts on this :)

Minor nits only.

You're welcome to do s/man-page/manual\ page/ for the title. :)

In D24829#546530, @jamie wrote:

Might it also be useful to include something similar on the stop side, run after taking down the IP addresses? I can't think of a use offhand, unless one wants to leave absolutely no trace of jails, and remove everything that was added in exec.prepare.

Remove BUGS section

Add licese, taken from commiters guide and bump .Dd

Bumping this, in the hopes it doesn't get lost.

Adding the diff via the website apparently accepts the key, whereas php-arcanist fails silently.

Syntactically and lexicographically, this makes sense to me.
As to whether it matters kernel-defined behavior, that's outside my area of expertise.

For compatibility's sake, I think using <br /> (ie. a space between r and forward-slash) is better.
Some older browsers require and while newer browsers seem to do fine with either, they certainly don't complain.

Cross-reference man-pages listed in this document

I must've missed .Fx on a separate line the first time around.

Fix .Fx macro to be on its own line

Replace Xr with Nm as it, at least in less, bolds the commands making it easier to read.

Glad to have so many reviews :)

Remove ministat, add stat, remove erroneous comma, wordsmithed the history section, and addressed issue to clarify that FreeBSD base contains more than just man-pages.

In D24417#537074, @allanjude wrote:

Not sure if ministat belongs on the list. It is more for doing statistical analysis, it doesn't actually give you any stats/status about your system

I believe I've addressed the issues.

Address typo, .Fx, macro usage, s/Cm/Xr/g, capitalization, inconsistent period, and wordsmithed a bit.

There is a generated html file of the first version of the man-page available here.

I was unsure about bumping the $FreeBSD line so I opted not to.
Is there documentation for when it should be updated?

I already did correcting and typo passes when commiting/merging these to the freebsd/freebsd-quarterly github repo, so it has my implicit approval. :)

Looks good to me now.

For the entire document, please do s/screenreader-friendly/screen-reader friendly/g so that it uses the same verbiage.

According to mdoc(7), the .Li macro is deprecated - should Ql be used instead?

Anyone who's still using tcsh after all these years might recognize that export is a Bourne shell thing - but it's absolutely vital that it's documented in case new people come along.

I don't wish to cause unnecessary noise, but it seems the accepted-status got lost in bumping things, so I'm wondering if you lost track of this review as I did?

I hope it's okay that I'm (apparently) combining two reviews into one? Or should I resubmit on each? I thought arc could handle multiple outstanding reviews, but apparently not.

Added recently discovered filename tag around /dev

Looks good to me, but I'll defer to other people to approve.
You might also wanna check with igor, as mentioned on IRC.

Add some examples as suggested by cress.

When you get around to it, you're welcome to commit this - as I don't have src access. :)

Edited the date of the man-page.

I think it might be a good idea to add the docs group as reviewers for this.

Feel free to commit at your leisure then - since I still don't have svn access, just project membership (that I need to get setup).

If the VM high watermark levels are tweaked, OOM from ZFS on swap can be entirely avoided. Don't know if this is relevant?

The description of what it does makes sense, although I can't spot if that's actually what the code does.
Otherwise, LGTM.

I think you need to actually add them as reviewers?

The feedback I provided on the git repo has been fixed, so I'm more than happy with this change. I don't have permission to accept nor commit it, though.

I can't help with the review itself, but the least I can do for this excellent idea is to remind you that you'll want to add some reviewers so that your code can be reviewed. :)

Since this review touches more than the man-page, you may want to talk to a few commiters about getting it reviewed by them. The easiest way to find people is to look at who touched these files last (ie. via svn/git blame). :)

Since it's accepted, would it be possible for this diff to go into HEAD?

Is it okay to ask what the status of this is? Because it looks really useful!

I can't help you with a review, but I can certainly remind you that you should probably get some reviewers involved. :)

I can't review for you, but I think it would be smart if you got some individual reviewers attached instead of just the whole group?
It's a good idea though. :)

I'm not a commiter, but since this looks like a neat thing to have, may I suggest you get some reviewers added?
One way to find reviewers is to look through the code for who touched these bits (MFU/MRU-like) and then ask them if they want to review it, or send an email to the appropriate mailing list asking for reviewers.

Out of interest, who's taking care of the commit?

I hope this review isn't waiting on my feedback, since I just had a question that was answered. I can't actually review the code.

This might be a dumb question, but does the process title change often enough that setproctitle_fast() added in rS335939 should be used?

Found two things which may need some TLC.

Noticed only one thing, otherwise it looks good to me.

Looks good to me.

Looks Good To Me!

I had to double-check i.e vs. eg., and found that it scans, so it looks good to me.

Supply a patch that (should) work.

Turns out this revision didn't work, will update with a new diff that fixes it once I get the OK for the change.

They do, thank you. :)
Nom.

Applied the changes from rene@ after satisfying myself I understand why they were made.

Added entities properly, sorted alphabetically

Added forward slash on last variablelist tag.

I'm really not sure what I'm supposed to do about these entries (nor am I even sure where to add them), because upstream (linux drm/kms stack) doesn't seem to provide these man-pages and I'm not at all capable of writing them.

Looks Good To Me!

Corrected which drivers work for what cards.

Added amdgpu, and explain that radeonkms and amdgpu are in general used for older and newer graphcs respectively.

Added missing semicolon.

Fixed issues pointed out by bcr@

Remove exteneous article.

Avoid weasel words, in accordance with the documentation primer.

For posterity's sake, the context of this review is a conversation on Twitter regarding the state of xattr/EA in FreeBSD for ZFS, with a special eye to multi-labels.

Did you think about getting some reviewers attached for this, as well as fixing the various errors?
The reason I ask is because it doesn't seem like a bad change, but if it's going to go into the tree there's typically some sort of review process.

I shan't comment on it on the change itself, but have you considered getting some reviewers attached to this?
Changes to FreeBSD typically don't land automatically, and there usually has to be at least some sort of review process.