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.
