Don't forget to add relevant bits to TEST PLAN section so its clear (explicit) to reviewers/mentors that the change were run through, and pass QA:

In D17443#372892, @skozlov wrote:

In D17443#372344, @koobs wrote:

Looks good except for -Werror. This all matches the port WIP I have in my tree, except for the additions:

MANPAGENAME=        ixgbe
MANPAGELINKS=        ix if_ix if_ixgbe
​MAX_NETMAP_OSVERSION=        1199999  # Doesn't build w/NETMAP on 12

Will do. Do you have any specific warnings showing up for you?

Missing responses to: https://reviews.freebsd.org/D16863?id=47167#369395 - In particular:

Looks good except for -Werror. This all matches the port WIP I have in my tree, except for the additions:

Perfect

We must be able to QA ports with poudriere, even when they're RESTRICTED, whilst also retaining the ability for the 'package building for distribution' use-case to not violate license terms.

Any change fixing this issue was (and is) explicitly approved (subject to @emaste confidence in solution/QA) per bugzilla issue comment: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230214#c7

LGTM

In D17099#364458, @jrm wrote:

This is a quote from @koobs from a past review.

Python packages that provide end-user, console scripts, or other files in common/shared locations should tested to be, or made to be USE_PYTHON=concurrent safe. Concurrent safe means two package installs of the same port for different python versions (eg: py27-foo and py36-foo) do not conflict (each file in common locations has a unique filename). USE_PYTHON=concurrent handles most common examples automatically (localbase/bin/*, docs).

@matthew Syntactical change looks fine, but I'd want to test dependents for compatibility given the major version bump. I'd expect to find some that pinned pbr to < 4

Accepted with port ordering change (it should go below USES)

Accepted, with two minor review items that while aren't 'strictly' necessary, are good for consistency (both for individual ports, and against other similar ports)

Merge security updates and all non-version updates to the quarterly branch when/where possible. I've added MFH to the proposed commit log message

Except for this probably requiring a PORTREVISION bump since the package contents are changed, it appears fine, assuming *all* the lines being removed are relevant to that GCC_RUNTIME.

Nice work, looks good!

This LGTM. @farrokhi Could you edit the revision SUMMARY to include a proposed commit log message please (including any relevant Property: value lines). Please include a link to a release notes, changelog, and link to any migration/upgrade notes (if required, this is a major version upgrade) and an explanation for USE_GCC removal (im assuming it just now builds with clang, but clarifying this in the message is nice)

Reopening

LGTM, thanks @loader!

@farrokhi Can you rebase your changes after @rm's commit and update the diff here

Looks good!

For future reviews, please include a proposed commit log message including rationale for changes (where not clear from the diff) in the SUMMARY section, and include QA confirmation in the TEST PLAN section, something like:

Use MASTER_SITES=CHEESESHOP by default for Python package distribution files when the source distribution (sdist) is published there (as this one is), unless there is a compelling temporary case to use an alternative source location (like GitHub); such as missing test files / important data files, etc. In these cases, ask upstream to include relevant files in the sdist

Thanks @garga

Lowercase RECAPTCHA_DESC

In D16365#348483, @delphij wrote:

In D16365#348482, @koobs wrote:

@delphij Is that acceptance for approval to MFH ?

Sorry, yes it is for MFH. Consider it pre-approved as long as maintainer (@koobs) accepts.

@delphij Is that acceptance for approval to MFH ?

Does this pass QA ?(testport for all supported freebsd versions/archs, make test)

Not sure why the the review wasn't automatically closed, possibly because i had (based on) after the differential ID

I have a WIP about to land, adding:

Does the change pass QA (poudriere) on supported/expected FreeBSD versions/archs without regression?

Feel free to omit any - itemized changes lines that just describe 'what' the diff already shows. The whys (causes, rationales, explanations) are the important bits in the log message.