- User Since
- Jan 12 2018, 3:33 PM (105 w, 3 d)
Wed, Jan 15
I think it might be a good idea to add the docs group as reviewers for this.
Sun, Jan 5
Sun, Dec 29
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).
Oct 26 2019
If the VM high watermark levels are tweaked, OOM from ZFS on swap can be entirely avoided. Don't know if this is relevant?
Sep 22 2019
The description of what it does makes sense, although I can't spot if that's actually what the code does.
Sep 6 2019
I think you need to actually add them as reviewers?
Aug 26 2019
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.
Aug 16 2019
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. :)
Jul 17 2019
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). :)
Jun 22 2019
Since it's accepted, would it be possible for this diff to go into HEAD?
May 24 2019
Is it okay to ask what the status of this is? Because it looks really useful!
May 20 2019
I can't help you with a review, but I can certainly remind you that you should probably get some reviewers involved. :)
May 19 2019
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. :)
Apr 10 2019
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.
Feb 26 2019
Out of interest, who's taking care of the commit?
Feb 25 2019
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.
Feb 17 2019
This might be a dumb question, but does the process title change often enough that setproctitle_fast() added in rS335939 should be used?
Jan 27 2019
Found two things which may need some TLC.
Jan 2 2019
Noticed only one thing, otherwise it looks good to me.
Dec 21 2018
Looks good to me.
Looks Good To Me!
Dec 20 2018
I had to double-check i.e vs. eg., and found that it scans, so it looks good to me.
Dec 11 2018
Nov 9 2018
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. :)
Oct 29 2018
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.
Oct 28 2018
Looks Good To Me!
Corrected which drivers work for what cards.
Oct 27 2018
Added amdgpu, and explain that radeonkms and amdgpu are in general used for older and newer graphcs respectively.
Oct 25 2018
Added missing semicolon.
Oct 24 2018
Fixed issues pointed out by bcr@
Remove exteneous article.
Avoid weasel words, in accordance with the documentation primer.
Oct 12 2018
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.
Oct 4 2018
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.