Re: Proposed ports deprecation and removal policy

On 28.02.24 22:18, Michael Gmelin wrote:
> 
> 
>> On 28. Feb 2024, at 20:22, Florian Smeets <flo@freebsd.org> wrote:
> 
> Hi Flo,
> 
> Thanks for the effort, it’s a delicate topic for many.

It is, we're tying our best and put some thought into it in the last 
coupe of weeks.

> 
>> Ports can be removed immediately if one of the following conditions is met:
>>
>> - Upstream distfile is no longer available from the original source/mirror (Our and other distcaches e.g. Debian, Gentoo, etc do not count as "available")
>> - Upstream WWW is unavailable: deprecate, remove after 3 months
>> - BROKEN for more than 6 months
>> - has known vulnerabilities that weren’t addressed in the ports tree for more than 3 months
>>
>>
>> A port can be deprecated and subsequently removed if:
>>
> 
> By whom though? Portmgr? Any committer?

Yes, this is a tough one. Obviously, first it's the maintainers job. If 
it's broken, vulnerable, etc. anybody can set DEPRECATED and remove it 
once it expires. How I saw this policy while writing it was as a 
guideline for maintainers and committers. Not something to allow 
committers to remove stuff at will that might fall under one of these 
points. But it will certainly be used to justify the start of glib20 
deprecation and subsequent removal, for example. But that is a topic for 
another day ;)

> 
>> - 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.
> 
> How many ports in the tree would be affected by this policy at the moment?

Honestly, I don't know. I'm not on a witch hunt for them. The policy is 
looking to make it easier to remove old stuff that hinders progress. If 
it's actively maintained, builds and is not vulnerable there should not 
be an issue. We are trying to make ports a bit more sustainable with the 
resources we have. e.g. look at the last PRs for the clang/LLVM updates.

> 
> Does “EOL versions“ also affect software where there are no new versions available (like, development officially stopped a long time ago or there was a license change, the project was archived etc.), or just outdated versions of software that is still under development? In any case, three months seems relatively short.
> 
> I’m maintaining a couple of ports where upstream officially stopped development, but which are still super useful (so they’re not just part of my personal software museum/there for sentimental reasons).

That is why we have lots of shoulds in the policy. Some of the policies 
might have been written with server software in mind too much that have 
different versions in parallel. e.g. PHP, asterisk, etc.

And yes, ports remaining or becoming more of a software museum is one of 
the things we want to combat with the policy to become more sustainable.

Florian