It would be good to have an explanation for the unexpected pkg-plist change, assuming its not influenced (confirmed with you on irc) or caused by the reinplace_cmd change

If its possible to make the commit log message more obvious that not fixing this ''will'' be an error after 229925, then do so, but not a dealbreaker

Is there a present or future (upcoming base change for example) impact of not removing the redundant escape? If so, clarify that in commit message

Anything that isn't a version update (unless its a security, bug fix release version update), is a MFH candidate. More precisely, there ought to be a reason (by policy or otherwise) not to MFH something, and in particular, merging things makes future merges easier (as one has to either commit all intervening commits anyway, or do direct to quarterly merges, which can be risky

For ports that have maintainers that have Phabricator accounts, its nice to add them to Reviewers: even if an existing PR exists and even in the case of an implicit/blanket/other approval, as a heads up

Additional changes:

In D23615#518777, @wulf wrote:

In D23615#518766, @koobs wrote:

Fails building in 11amd64 with the following, so will at least set OSVERSION > 12* unless its expected or desirable for iichid to be test on 11:

Only 12.1+ is supported.

11 requires some ig4 and ACPI bits to be MFC-ed.

Fails building in 11amd64 with the following, so will at least set OSVERSION > 12* unless its expected or desirable for iichid to be test on 11:

@imp @wulf This appears to build/package (poudriere) fine on 12amd64, should we leave it open for any version/arch, or should we limit it. If limiting, I need a list of archs for ONLY_FOR_ARCHS and OSVERSIONS we shouldn't set IGNORE for

Landing this today

Just adding review comments for posterity.

I'll help to get this landed in ports and can make the MAINTAINER change if Cy doesn't have cycles

Approved by: koobs (ports, mentor)

Note: First half of this comment were my thoughts/review before I realised the ports 'dual-named' nature. I left it in to show work/rationale ...

In D21570#507026, @joneum wrote:

I'll use the days to think about whether to give up my commit bit, and just continue as a normal maintainer.
The current incident has once again shown that people no longer communicate with others, but simply do what they want. And that is not my policy. It robs me of the fun.

@joneum You can abandon revisions instead of accepting/closing. Would you like the remain author on this?

Note: I have WIP updates to fix some of the errors

@neel_neelc.org I'd like to get this resolved. Could you reference the upstream commits/issues/merge requests this patch constitutes/ correlates with in the differential summary please, and include comments/references in the patch headers too

LGTM @loader :)

In D22688#499387, @koobs wrote:

@pkubaj I believe you can "Commandeer Revision"

@pkubaj I believe you can "Commandeer Revision"

Can we get a proposed commit log message in this reviews summary that explains the context/issue and the 'why' of the change please

Ping @sunpoet

Above review items are not deal-breakers. This change in principle/spirit is otherwise:

1. Suggested tweaks to DEPRECATED message for each of the py-dj21-* ports: