Re: Proposed ports deprecation and removal policy

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.