From owner-freebsd-ports@freebsd.org Sun Aug 30 08:28:15 2020 Return-Path: Delivered-To: freebsd-ports@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 03C453AAC22 for ; Sun, 30 Aug 2020 08:28:15 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4BfRL66N6pz4tf6 for ; Sun, 30 Aug 2020 08:28:14 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id DAC7D3AA8F1; Sun, 30 Aug 2020 08:28:14 +0000 (UTC) Delivered-To: ports@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DA9303AA953 for ; Sun, 30 Aug 2020 08:28:14 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.daemonic.se (mail.daemonic.se [176.58.89.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BfRL63TFGz4tf5; Sun, 30 Aug 2020 08:28:14 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 4BfRL42n6Wz3n08; Sun, 30 Aug 2020 08:28:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([127.0.0.1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [127.0.0.1]) (amavisd-new, port 10587) with ESMTPS id Ax6X94Mf5C2Y; Sun, 30 Aug 2020 08:28:11 +0000 (UTC) Received: from vivi.daemonic.se (vivi.daemonic.se [IPv6:2001:470:dca9:1200::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 4BfRL33PG5z3myt; Sun, 30 Aug 2020 08:28:11 +0000 (UTC) Subject: Re: Aggressive ports removal To: Greg 'groggy' Lehey Cc: FreeBSD Developers , ports@freebsd.org References: <202008291154.07TBsr7L086597@repo.freebsd.org> <9a4583d9-097e-d0ba-4959-5c4d7b96b611@freebsd.org> <20200829232707.GC46173@eureka.lemis.com> From: Niclas Zeising Message-ID: Date: Sun, 30 Aug 2020 10:28:10 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200829232707.GC46173@eureka.lemis.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4BfRL63TFGz4tf5 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:36236, ipnet:176.58.89.0/24, country:US]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 08:28:15 -0000 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