Page MenuHomeFreeBSD

Committer's guide: Fix about (re)moving ports
ClosedPublic

Authored by salvadore on Mon, May 2, 10:41 PM.

Details

Summary
  • Move consideration about security vulnerabilities from instructions for removing ports to instructions for moving ports.
  • Reword the above consideration to take into account the splitting of vuln.xml into one file per year.

Diff Detail

Repository
R9 FreeBSD doc repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

salvadore created this revision.

s/into/inside/ is minor enough to be done right before committing. Other one is a suggestion, not a request.

documentation/content/en/articles/committers-guide/_index.adoc
3748

In addition, maybe future-proof this by making it more specific, eg using "vuln*.xml" instead of "xml"?

This revision is now accepted and ready to land.Mon, May 2, 10:53 PM

I think updating vuxml indeed makes more sense when moving ports.

@pauamma_gundo.com and @rene: thank you very much for your review. I will indeed s/into/inside/ as requested by Pau Amma before committing.

@ docs: According to the committer guide I need an approval from a not mentored doc committer to commit to doc/, as I am ports committer, but I have seen Pau Amma set the docs approval: should I consider approval from Pau Amma as good as doc committer approvals for committing to doc/ ? Thanks.

documentation/content/en/articles/committers-guide/_index.adoc
3748

I prefer to keep it less specific, I think this is the most future-proof strategy. Today we have indeed all those files starting with 'vuln', but some day we might change this convention for some reason. On the other hand, if the format (xml) ever changes, then the directory name ('vuxml') would change too and we would have to correct those lines anyway.

carlavilla added a subscriber: carlavilla.

Approved from docs

Approved from docs

Thank you, @carlavilla! Also approving (mostly pro-forma) as mentor.

I have seen Pau Amma set the docs approval: should I consider approval from Pau Amma as good as doc committer approvals for committing to doc/ ? Thanks.

docs and the Doc committers group are different. Based on a discussion in a previous review, I'm allowed to approve on behalf of docs, but if you (also) need approval from a committer, you may want to list both as group reviewers.

I have seen Pau Amma set the docs approval: should I consider approval from Pau Amma as good as doc committer approvals for committing to doc/ ? Thanks.

docs and the Doc committers group are different. Based on a discussion in a previous review, I'm allowed to approve on behalf of docs, but if you (also) need approval from a committer, you may want to list both as group reviewers.

@pauamma_gundo.com: Thanks Pau Amma, but I am still confused: in the past I have been asked to ask for reviews from docs instead of the Doc committers group, but the committer's guide requires me to ask approval from a doc committer.

docs: Which approval do I need to commit to doc/ as a ports committer? Approval from a doc committer or approval from docs? In the second case, I think we should state it clearly in the committer's guide (I can provide a patch, if it helps). Thanks.

The committer’s guide is right. You need an approval from a doc committer.
Another history is if you can make a commit with the approval of Pau Amma. For me there’s no problem. But this is an exception, not a rule that should be added to the committer’s guide.
PS: The Pau Amma’s approval is a personal opinion. Not from the Doceng.

@carlavilla: Thank you very much for your answer. I will keep asking for a doc committer approval as usual then.

The committer’s guide is right. You need an approval from a doc committer.
Another history is if you can make a commit with the approval of Pau Amma. For me there’s no problem. But this is an exception, not a rule that should be added to the committer’s guide.
PS: The Pau Amma’s approval is a personal opinion. Not from the Doceng.

Just to be clear: docs gives the author more reviewers. That's where (and how) I come in. Per discussion with... I think it was @kevans in an earlier review, I'm allowed to approve on docs' and manpages' behalf in addition to my own, and that indeed doesn't mean a doc committer approved anything, or even knows of the review. So perhaps, in addition to the Committer's guide procedures, which I'm actually not talking about, listing both docs and the Doc committers group in Group Reviewers may make it clearer who does what?

@pauamma_gundo.com : Thanks for your suggestion, I will try to do that. Indeed, it seems the solution that makes more sense.

The committer’s guide is right. You need an approval from a doc committer.
Another history is if you can make a commit with the approval of Pau Amma. For me there’s no problem. But this is an exception, not a rule that should be added to the committer’s guide.
PS: The Pau Amma’s approval is a personal opinion. Not from the Doceng.

Just to be clear: docs gives the author more reviewers. That's where (and how) I come in. Per discussion with... I think it was @kevans in an earlier review, I'm allowed to approve on docs' and manpages' behalf in addition to my own, and that indeed doesn't mean a doc committer approved anything, or even knows of the review. So perhaps, in addition to the Committer's guide procedures, which I'm actually not talking about, listing both docs and the Doc committers group in Group Reviewers may make it clearer who does what?

This is correct. The addition of both groups will allow more people to check the review. I think this is a good procedure :)