Re: Proposed ports deprecation and removal policy

On 28.02.24 22:09, Charlie Li wrote:
> 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.

The sentence you refer to is just a rough summary of what is described 
in more detail further down. e.g.

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


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

I don't understand what you are trying to say with the first sentence. 
It's kind of implicit that we will not allow removal of libraries that 
still have (lots of) ports depending on them with this policy. But we 
should probably make this explicit. I'll add a note and come up with 
something.

Thanks
Florian