Re: Proposed ports deprecation and removal policy

On 2/28/24 12:22, Florian Smeets 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.

   Not otherwise mentioned in this post, there is value in considering 
the difference between unmaintained upstream, unmaintained from an 
inactive port maintainer, unmaintained from an interested port 
maintainer that is unable to solve the problems they have been presented 
with or find helpers who did, and unmaintained due to no maintainer for 
the port.
   Is there a recommendation, and way to go about it, for port 
maintainers to preemptively mention extended away time like 
vacation/holiday or longer?

> 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.

   I presume 'progress' means things like 'blocks ports framework 
updates' as cases were mentioned of later, but was this the intent? 
Removing a port that causes conflict building/installing another could 
be considered progress.

> 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")
> - Upstream WWW is unavailable: deprecate, remove after 3 months

   As some ports don't really have a WWW this may be a bit harsh in 
special cases where community interaction beyond source code is through 
a mailing list, chatroom, discord, etc. Some websites may be neglected 
or left to expire due to little interest from who ran it even though a 
project isn't similarly dead.

> - BROKEN for more than 6 months

   Presume this is a 'broken for everyone on supported FreeBSD releases' 
though should probably also include stable and current before deletion 
can happen.
   I have seen results, besides just a 'BROKEN' being set, from ports 
with maintainers that had a PR with a maintainer's patch that fixed a 
problem go for months without being committed. I hope a rush to 
mark/remove ports as this email implies would lead to more efficient 
flow rather than creating more work by actions that would be a mistake 
in such cases.

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

   Will the scope of a vulnerability be considered? As an example, 
removing virtualbox because of a network vulnerability means users who 
do not need such capability lost the port too.
   Trying to follow CVEs has made it clear to me that some end up being 
bugs or possibly unexpected program operation that doesn't seem to have 
any known example of how the bug is even a security issue.

> 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.

   Are we thinking of 'old version' cases such as python27, or even 
cases where upstream EOL'd the project as a whole? Would it be handled 
differently if an alternative exists or not and if an alternative 
community can be switched to for further project coordination?

> - 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

   Some ports are not hier compatible in general even though they are 
still useful ports. How are exceptions to be decided? Are they marked as 
an exception in the Makefile?

> 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
> 
> Florian (on behalf of portmgr)

   No maintainer + no upstream maintenance when issues have arisen 
(security, build, infrastructure compatibility) seems like a good time 
for marking for removal as a general concept though it seems many ports 
I use, or just try out, regularly don't have maintainers. As issues 
arise, people often step up and report them or fix them as nonmaintainer 
which then get committed. I feel I'm not the best choice for maintainer 
as I am not active enough and often find I go periods where I don't pay 
active attention; my email often goes through phases where it doesn't 
get looked at if I'm not actively looking for something. I also found 
through experience that simple porting problems often go beyond my 
abilities.
   Some ports would likely benefit from just having a maintainer as 
someone who coordinates the effort to keep it working even creating the 
port+patches is beyond them. This could be a point of failure if they 
recommend submitted patches be committed without requesting outside help 
reviewing them such as for safety. Could we document more clearly if 
such a maintainer is desired and if it is, even recommend it in the 
all-too-common 'this port has no maintainer' messages?
   Similarly, pkg could really benefit from listing that message once 
with a list of ports it applies to as I find the messages basically just 
become noise at this point.