Florian Smeets wrote:
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.
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

These reasons are good on first read but the premise needs to be worked in earlier. Also need to consider actively-maintained and supported software that happen to use EOL dependencies.

--
Charlie Li
...nope, still don't have an exit line.

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to