Developer mode

[Ryan Schmidt]

On Nov 19, 2019, at 18:21, Ralph Seichter wrote:

> * Ryan Schmidt:
> 
>> We might also add a way for a developer to indicate for which ports
>> developer mode should be turned on. A developer might wish, for
>> example, to be notified of issues relating to the ports they maintain
>> but not the ports that others maintain.
> 
> That can be useful. Is that not something Trac should handle? If a
> ticket references a specific port, is the designated maintainer not
> automatically added to the ticket?

As Rainer said, no, Trac does not auto-assign tickets to the ports' maintainers, but I'm not talking about tickets. I'm talking about deprecated features in MacPorts where we would like maintainers to migrate to more modern equivalents. We do some of this in `port lint` already (for example we already advise that `eval [glob ...]` is deprecated and should be replaced with `{*}...`) and could do more there (like recommending replacing `PortGroup cxx11 1.1` with `compiler.cxx_standard 2011`), but developers have to run lint explicitly, and I'll bet that usually they don't (I don't) and so some of the recommendations made by lint go unheeded for years. I am proposing that MacPorts base should perform lint and other checks as the port is being used by its maintainer and alert the maintainer about any problems so that the maintainer can take care of it without anyone needing to file a ticket about it.

Some checks can't be done at lint time. For example, I have an experimental branch of base that warns if the port may be using a configure script that suffers from the "Yosemite libtool" bug (where OS X 10.10 and later are misidentified as Mac OS X 10.1). I am not personally going to examine all of the over 23,000 ports right now to see which of them suffer from this problem and file tickets for each of them; I don't have the time to do that. Instead, I am proposing that messages about this type of problem would be shown at the new "developer mode" output level which developers could opt into.