Aggressive ports removal (was: svn commit: r546907 - head/x11-clocks/wmtime)

[Greg 'groggy' Lehey]

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.

My suggestion:

  1. Decisions to deprecate remove ports should be made only by
     portmgr at .
  2. Ports are not broken because they don't easily adapt to some new
     ports framework.
  3. Ports should not be removed without community consultation, which
     should last for at least n months, with m reminders being sent.

Greg
--
Sent from my desktop computer.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20200830/27521e8a/attachment.sig>