Aggressive ports removal

[Niclas Zeising]

On 2020-08-30 01:27, Greg 'groggy' Lehey wrote:
> Sorry for the length of the quotes, but I've added people who might
> not have seen the (relatively long) thread on this subject.  This
> seems the best message to refer to.
> 
> On Saturday, 29 August 2020 at 16:09:12 +0200, Stefan Esser wrote:
>> Am 29.08.20 um 15:32 schrieb Niclas Zeising:
>>> On 2020-08-29 14:48, Michael Gmelin wrote:
>>>> As I???ve seen quite a lot of similar commits:
>>>>
>>>> Is our policy now to deprecate ports (with one month notice) that
>>>> aren???t maintained/have a dead upstream, even though the ports still
>>>> work okay and aren???t the type that requires much maintenance anyway?
>>>>
>>>
>>> Hi!
>>> As far as I know, there is no official policy, this was something that
>>> Tobias (tcberner@) and I (mostly I) agreed on, since we're doing a lot
>>> of the lifting when it comes to -fno-common.
>>>
>>> However, there is a lot of stale, old, unmaintained and possibly broken
>>> software in the Ports tree, and I viewed this as a chance to clean out
>>> some of the cruft.  All these ports take resources from people needing
>>> to fix them, from the build cluster which is building them, and so on.
>>> Since there is no upstream fix for -fno-common, and there is no
>>> maintainer, I thought it would be a good idea to deprecate such ports,
>>> since there is no apparent interest in them.  -fno-common is the new
>>> standard way of building C code (both llvm 11 and gcc 10 defaults to
>>> it).  If someone is interested in the port, they can easily submit a PR
>>> to maintain the port and remove the deprecation (or commit the fix, if
>>> they are a FreeBSD committer).
>>> If they are removed, and someone in the future decides to take care of
>>> one (or more) of them, they can easily be resurrected, since they will
>>> live on in SVN (and git) history.
>>
>> No maintainer and no changes for a long time does not imply that there
>> is no interest in a port!
>>
>> If it just works, serves its purpose for those using a minimal X11
>> environment (there are still twm users) and there is no indication
>> of a lingering security problem, then why depreciate and later delete
>> such a working port?
> 
> Exactly.  Another case in point: x11/xtset.  Maintenance stopped in
> 1993, 11 days after the FreeBSD project came into existence.  It works
> fine, and I find it very useful.  If at some time in the future it
> should no longer work with the latest and greatest iteration of the C
> programming language or ports structure, that shouldn't be a reason to
> discard it.

Then it is very easy.  If it is useful to you, adopt it as maintainer, 
then you will get a notification if it fails to build, and you can fix 
the issue(s), instead of trusting that someone has the time and energy 
to fix it.  At the same time you indicate that there is actually some 
interest in the port.
We set deprecation dates in the future so that interested parties should 
have a chance to speak up.

> 
> My suggestion:
> 
>    1. Decisions to deprecate remove ports should be made only by
>       portmgr at .

This is like saying you don't trust ports developers.  Any work on the 
ports tree would grind to a complete halt.

>    2. Ports are not broken because they don't easily adapt to some new
>       ports framework.

This is simply not true.  Ports that don't adopt to a new ports 
framework are broken.  New ports frameworks are developed to ease in 
porting, packaging or to improve or simplify ports, the same way as new 
kernel or base frameworks are invented.  Things that do not comply with 
the new way of things are hindering progress and updates, and need to be 
either adapted or removed.
It is exactly the same as for instance the removal of the Giant lock. 
The difference might be the rate of change.  Since FreeBSD base has 
fixed releases and stable branches, but the ports tree mostly a rolling 
release model (that has to work on 3-4 different FreeBSD versions at the 
same time) the rate of change in the ports tree are necessarily higher.

>    3. Ports should not be removed without community consultation, which
>       should last for at least n months, with m reminders being sent.

I agree with the reminders.  Every time you install a deprecated port or 
package you'll get just such a notification.
Regards
-- 
Niclas Zeising