Re: Proposed ports deprecation and removal policy

Hi,

A few comments on the proposed ports deprecation and removal policy, there will be some quotes for context by multiple people and adress multiple mails.

I would recommend that we in general set DEPRECATED, EXPIRATION_DATE  (2w to 1m minimum), mark BROKEN if needed before removal to avoid unnecessary frication and give people a chance to raise a discussion if needed. Possibly with the exception of major library updates etc or perhaps if we have a reasonable threshold. I do however think that people in general surpass the exceptions of keeping ports buildable without deprecating even today.

> - Upstream distfile is no longer available from the original source/mirror (Our
> andother distcaches e.g. Debian, Gentoo, etc do not  count as "available")

Agreed, in addtion it can be an indication that upstream is dead/inactive/abandoned project but you as a committer should be able to determine the current situation without spending too much time on it. I honestly think we can leave it up the committer as at least myself would trust people to have a suitable threshold (a few days or so) rather than something ridicious like 1h or so.

This will of course also include an overall review of the "usability"/usefulness and if it's maintainable. For example, if lets say telnet client (I'm aware its not a port but for the sake of giving an example) upstream site goes away it may be worth rehosting it as it's likely not going to change, evolve or cause major maintenance issues (noise) further down the road and is still of use. If it's a WAP (the old Wireless Application Protocol) specific server daemon that would on the other hand be reasonable to consider deprecating. At the end it all boils down to doing a resonable assessment 

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

Older but still useful ports may not have one, perhaps have a universal tag to easily tag such ones?
WWW= LEGACY-BLANKET-UNAVAILABLE or something along those lines?

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

As for security issues as people have discussed far from all are reported as CVEs despite being pretty serious. 
Examples: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264186 -->
https://github.com/mikebrady/shairport-sync/issues/1478,

audio/alacenc --> https://github.com/flacon/alacenc/issues/1

So it shouldn't be CVEs alone

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

> The phrasing "blocks progress" is problematic. Progress of what? 
> Indiscriminately hunting down EOL/apparently inactive software? Mass 
> migrating from one build system to another due to primarily personal 
> preference, even against upstreams' will? This phrasing is vague enough 
> to justify deprecating and removing, say EOL (but still fetchable and 
> buildable) libraries needed by actively-maintained and supported (and 
> popular) software that are in no rush to migrate away. If this vagueness 
> is intended, then it needs to be accompanied with *us* actively 
> developing in the upstream project to support efforts here.

This fall upon the committer to be reasonable, if a project is still stuck on lets say boost 1.66 and falls under the not active section than it's subject to removal. There will of course be some edge cases that affects many and/or the projects infrastructive that need a more public discussion (a reasonable delay to catch up) but in general there shouldn't be any issues in general with this policy.
For recent examples audio/taglib (PR 276677) and multimedia/ffmpeg (PR 261302) are good acceptable ways of handling these types of issues in general.
We do need to sunset ffmpeg4 eventually however...

We do forking with multiple versions at times but those seem to cause more issues  that they solve and often conflicts with each other.

Concerning ports the depends on software that's EOL

This fall upon the committer to be reasonable, if a project is still stuck on lets say boost 1.66 and falls under the not active section than it's subject for removal. There will of course be some edge cases that affects many and/or the projects infrastructive that need a more public discussion (a reasonable delay to catch up) but in general there shouldn't be any issues in general with this policy. For recent examples audio/taglib (PR 276677) and multimedia/ffmpeg (PR 261302) are good acceptable ways of handling these types of issues in general. We do need to sunset libraries such as ffmpeg4 eventually so it's not a long term solution.

EOL dependencies are considered unmaintained and officially unsupported, of course a reasonable amount of time (a few months) should be allowed for upstream to catch up but otherwise the port should go as it's very likely to have security issues, build and maintainability among other concerns. If specific users feel there's a need to keep the port and its dependencies Poudriere supports overlays so they can still continue to use it outside the official tree. There could even potentially be an unofficial overlay outside the project called ports-legacy-overlay or whatever that's maintained by the community if there's interest. We wont be able to cater everyones specific needs but we can however try to make a best effort about it within reachable limits.

It's very easy to claim that we should support * until the end of time but that's not being realistic and in most cases originates from lack of maintaince upstream for one or another reaon or within the tree. We already have an uphill battle with several ports trying to keep them at least buildable due to this. What happens in practice that people trying to keep these libraries up to date will eventually burn out or lose interest prematurely. It should also be mentioned that buildable doesn't necessarily mean functional and it's not a software museum.

> - Software hasn’t seen a release in a long time
> - Upstream looks inactive for a long time
This is problematic in practice as that doesn't cover abandonware and similar situations a upstream project may be in but rather protects all ports including those that have a maintainer but is inactive. I do agree on that a port per se shouldn't be removed determined by its age alone.

A few aspects that should be included and taken into consdieration: 
- Deprecated in terms of coding (we need to manually patch it from time to time in order to keep it buildable)
- Obvious bad practice, example VPN software only supporting DES for encryption
- Counterparts/replacements are available (either within ports or outside and are somewhat closely similar)
Note: While I don't think we should dictate what users should/shouldn't do I think there is some "responsibility" implied as we do have a "Ports Security Team" regarding this topic
- "Cruft", obsolete stuff that has little to no value today. Such as "netbus" (Windows) clones, software for interfering with 15+ old MP3 devices or an abandoned VCS
There should always be a PR created  (if maintained) and/or a resonable expiration date if people want to raise discuss the decision with fair arguments
I still feel much of this falls under the "being reasonable" with the committers discretion in mind in the end.

A deprecation notice "bot" sounds like a good idea like delphij@ suggested

I would also raise concerns about one man band forks regarding abandonware, some projects flat out refuse these in their guidelines and for most of the time it's likely justified. While I dont think necessarily there's a need to refuse these I would also on the other hand be reluctant to define these as "maintained"  as a way to work around policies just because or even add these to the tree in the first place.

As for the ongoing work in general, I've tried to keep an open dialog about it and the majority of interractions have been very been positive overall. We do however carry a bunch of lang related ports (p5, php, python etc)  that needs to be looked at some point.

Best regards,
Daniel (diizzy@)