Re: Proposed ports deprecation and removal policy

On Wed, Feb 28, 2024 at 11:22 AM Florian Smeets <flo@freebsd.org> wrote:

> Dear ports community,
>
> as the removal of ports is a recurring source of friction and dispute we
> would like to add a ports removal and deprecation policy to the porters
> handbook.
>
> We tried to find a sensible middle ground between too fast removal and
> keeping unmaintained and abandoned upstream software in our ports tree
> forever.
>
> When can or should ports be deprecated or removed?
>
> This policy should give some guidance on when ports can or should be
> removed. In general ports should not be removed without reason but if a
> port blocks progress it should be deprecated and subsequently removed.
> In general, if a ports blocks progress for some time it will be removed
> so that progress can be made. For more details see below.
>
>
> Ports can be removed immediately if one of the following conditions is met:
>
> - Upstream distfile is no longer available from the original
> source/mirror (Our and other distcaches e.g. Debian, Gentoo, etc do not
> count as "available")
>

I have no objection with removing a port if upstream all died and nobody
cared, but removing them "immediately" seems to be too harsh and not
friendly for smaller software vendors.  For example, bzip2 got their domain
name stolen, but the project didn't really die and continued at
sourceware.org.  Please give the maintainer some time (e.g. by marking the
port as DEPRECATED with a timeout time, maybe two weeks, maybe a month or
even 3 months).


> - Upstream WWW is unavailable: deprecate, remove after 3 months
>

Could you please explain why upstream WWW would warrant a removal?  (I
think removing the WWW= entry if the website is compromised or is no longer
available is perfectly fine, but why remove the port itself?)


> - BROKEN for more than 6 months
>

I think if a port won't build on any of the official FreeBSD.org
package cluster, the port is marked BROKEN with a deprecation period of 6
months (personally I think it's too long, 3 months should be the maximum).

This should include ports that are IGNORED for all supported platforms and
conditionally broken with all supported defaults: they should have correct
dependency and are able to build in at least one poudriere environment.


> - has known vulnerabilities that weren’t addressed in the ports tree for
> more than 3 months
>

I think this is somewhat too vague.  Known to whom?  Registered at
cve.mitre.org?  In vuxml?

Probably something like: if vuxml thinks the port is vulnerable, then it's
marked FORBIDDEN immediately with a 3 month timeout (personally I think 2
weeks would be the maximum) by some automated script, and after the set
time of being FORBIDDEN, the port is eligible for immediate removal.


> A port can be deprecated and subsequently removed if:
>
> - Upstream declared the version EOL or officially stopped development.
> DEPRECATED should be set as soon as the planned removal date is know.
> (It is up to the maintainer if they want to remove the port immediately
> after the EOL date or if they want keep the port for some time with
> backported patches. Option two is *not* possible without backporting
> patches, see vulnerable ports) The general suggestion is that EOL
> versions should not stay in the ports tree for more than 3 months
> without justification.
> - The port does not adapt to infrastructure changes (i.e. USE_STAGE,
> MANPREFIX, compiler updates, etc.) within 6 months. Ports should be set
> to DEPRECATED after 3 months and can be removed after 6
>
>
> Reasons that do not warrant removal of a port:
>
> - Software hasn’t seen a release in a long time
> - Upstream looks inactive for a long time
>

IMHO, a lot of "friction" comes from lack of communication and not port
getting removed themselves.

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

or, if it's just one port:

ACTION REQUESTED: category/port is marked as DEPRECATED and will be removed
on 1 month
====
Hello,

This is a friendly notification from FreeBSD port deprecation bot.  In the
latest scan the following ports you maintain are marked as DEPRECATED:

Port name     | Removal date
category/port | 2024-03-30
...

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.

Cheers,