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@.
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
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
