Date: Sun, 30 Aug 2020 10:28:10 +0200 From: Niclas Zeising <zeising@freebsd.org> To: Greg 'groggy' Lehey <grog@FreeBSD.org> Cc: FreeBSD Developers <developers@freebsd.org>, ports@freebsd.org Subject: Re: Aggressive ports removal Message-ID: <f9cd7c4d-9477-89ab-f054-75b9bf9ca077@freebsd.org> In-Reply-To: <20200829232707.GC46173@eureka.lemis.com> References: <202008291154.07TBsr7L086597@repo.freebsd.org> <FC66C7DA-2A0D-43E7-B29C-E4C94C1973BA@freebsd.org> <f56625f8-1d63-515c-93af-909a4e47e65d@freebsd.org> <9a4583d9-097e-d0ba-4959-5c4d7b96b611@freebsd.org> <20200829232707.GC46173@eureka.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >=20 > 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 stil= l >>>> work okay and aren???t the type that requires much maintenance anywa= y? >>>> >>> >>> Hi! >>> As far as I know, there is no official policy, this was something tha= t >>> Tobias (tcberner@) and I (mostly I) agreed on, since we're doing a lo= t >>> of the lifting when it comes to -fno-common. >>> >>> However, there is a lot of stale, old, unmaintained and possibly brok= en >>> software in the Ports tree, and I viewed this as a chance to clean ou= t >>> some of the cruft.=A0 All these ports take resources from people need= ing >>> 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.=A0 -fno-common is the ne= w >>> standard way of building C code (both llvm 11 and gcc 10 defaults to >>> it).=A0 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, i= f >>> they are a FreeBSD committer). >>> If they are removed, and someone in the future decides to take care o= f >>> one (or more) of them, they can easily be resurrected, since they wil= l >>> 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? >=20 > 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,=20 then you will get a notification if it fails to build, and you can fix=20 the issue(s), instead of trusting that someone has the time and energy=20 to fix it. At the same time you indicate that there is actually some=20 interest in the port. We set deprecation dates in the future so that interested parties should=20 have a chance to speak up. >=20 > My suggestion: >=20 > 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=20 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=20 framework are broken. New ports frameworks are developed to ease in=20 porting, packaging or to improve or simplify ports, the same way as new=20 kernel or base frameworks are invented. Things that do not comply with=20 the new way of things are hindering progress and updates, and need to be=20 either adapted or removed. It is exactly the same as for instance the removal of the Giant lock.=20 The difference might be the rate of change. Since FreeBSD base has=20 fixed releases and stable branches, but the ports tree mostly a rolling=20 release model (that has to work on 3-4 different FreeBSD versions at the=20 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=20 package you'll get just such a notification. Regards --=20 Niclas Zeising
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f9cd7c4d-9477-89ab-f054-75b9bf9ca077>