Re: Proposed ports deprecation and removal policy

Florian Smeets wrote:
> 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.
> 
Unfortunately, implicitness in this regard in the beginning of the 
document is easily lost. "Blocks progress" can still mean blocking an 
individual's witch hunt to cull all EOL or apparently inactive ports 
without doing any real usage analysis. This is certainly not to trend in 
support of any software museum vibes, but the point about due diligence 
in say, inactive or infrequently-committed to source code doesn't 
automatically mean old and abandoned (some software literally don't need 
more frequent commits or updates) needs to be more up-front and not in 
some detail further along in the document.

You don't need lots of consumers of an EOL software to sow friction in 
the community; just one actively-maintained and supported upstream 
software that uses said EOL dependency is enough. And when someone other 
than the listed maintainer vies for deprecation/removal of said EOL 
software with consumers, the onus has to be on the proponent to actively 
help the upstream projects in migrating away (upstream bug reports are 
not enough), including certifying those changes make it into upstream 
releases.

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