Re: Proposed ports deprecation and removal policy

On 2024-03-02 17:48, Hubert Tournier wrote:
> On Thu, 29 Feb 2024 19:26:23 UTC, Xin LI wrote:
> 
>> For example, one of my port gets marked as DEPRECATED because a dependency
>> was deprecated and scheduled for removal after 1 month, without any email
>> telling me so (the port doesn't have a lot of releases and there isn't any
>> release during that "parole" month), and it gets removed after that.  So in
>> order to know there is an ongoing deprecation of the port, I as a port
>> maintainer would have to either watch the directory for any changes, or
>> read all ports-git commit messages or at least a filtered version of it,
>> and that's burdensome and inefficient use of developer time at best.
> 
>> What I would love to see happen is that, when a port gets marked as
>> DEPRECATED, there is an automated system that sends me notification with
>> something like:
> 
>> ACTION REQUESTED: X new ports you maintain is marked as DEPRECATED
> 
> [...]
> 
>> and that email gets sent every 7 days until the port is removed or the
>> issue is fixed.  Or a bug is created and assigned to the maintainer, etc.
IMHO Depreciation should performed via pr(1) -- the bugzliia bug reporting
system we already use for bugs. I'm on the commits-ports-all@ list
which is a noisy list. I'm maintain over 100 ports, so it seems justified.
But someone with a dozen or less ports, joining ports-all list would probably
seem too large a burden. We want to encourage participation, not discourage
it. Bugzilla should be the required path for DEPRECIATION. All maintainers
are already notified automatically. So this seems like the most efficient
path for all concerned.

-- 
Chris Hutchinson