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:

If this is a copy of an existing port, create the new port using svn copy (as this is what committers will have to do). Also have the benefits of that copy being tracked and displayed in the phabricator differential, and showing the diffs to the original source (so we know whats been updated/changed, rather than everything being new)

Personally I'd go with changing the pyqt format to the more consistently used in the tree <component>:<target> format but that's a more invasive change requiring a substantial amount of existing port churn. It would be good as a second step evolution of pyqt.mk to bring it in line with the rest of the framework

Uses/pyqt.mk should grow either standard support for :[build,run,test] args, or if it cant in its current state (it currently supports a <component>[_build|_run] format), then it should support <component>[_test] too, allowing those dependencies to be set only as test dependencies

I'm not C savvy, so probably not appropriate for review (but thanks for adding me so I was aware of the change)