From owner-freebsd-ports@freebsd.org Sat Aug 29 23:27: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 CAB1C3C1484 for ; Sat, 29 Aug 2020 23:27:15 +0000 (UTC) (envelope-from grog@lemis.com) 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 4BfCKv4MdGz4FVb for ; Sat, 29 Aug 2020 23:27:15 +0000 (UTC) (envelope-from grog@lemis.com) Received: by mailman.nyi.freebsd.org (Postfix) id 9412E3C0FC0; Sat, 29 Aug 2020 23:27:15 +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 93D963C1244 for ; Sat, 29 Aug 2020 23:27:15 +0000 (UTC) (envelope-from grog@lemis.com) Received: from lax.lemis.com (www.lemis.com [45.32.70.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4BfCKt4S6Zz4FSH; Sat, 29 Aug 2020 23:27:14 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (aussie-gw.lemis.com [167.179.139.35]) by lax.lemis.com (Postfix) with ESMTP id 2878627FF9; Sat, 29 Aug 2020 23:27:08 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id 84EA026359A; Sun, 30 Aug 2020 09:27:07 +1000 (AEST) Date: Sun, 30 Aug 2020 09:27:07 +1000 From: Greg 'groggy' Lehey To: Stefan Esser Cc: Niclas Zeising , Michael Gmelin , FreeBSD Developers , tcberner@FreeBSD.org, ports@freebsd.org, portmgr@freebsd.org Subject: Aggressive ports removal (was: svn commit: r546907 - head/x11-clocks/wmtime) Message-ID: <20200829232707.GC46173@eureka.lemis.com> References: <202008291154.07TBsr7L086597@repo.freebsd.org> <9a4583d9-097e-d0ba-4959-5c4d7b96b611@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DIOMP1UsTsWJauNi" Content-Disposition: inline In-Reply-To: <9a4583d9-097e-d0ba-4959-5c4d7b96b611@freebsd.org> Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: http://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) X-Rspamd-Queue-Id: 4BfCKt4S6Zz4FSH X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of grog@lemis.com has no SPF policy when checking 45.32.70.18) smtp.mailfrom=grog@lemis.com X-Spamd-Result: default: False [-2.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.66)[-0.662]; FREEFALL_USER(0.00)[grog]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.89)[-0.886]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[FreeBSD.org]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-0.63)[-0.633]; RCPT_COUNT_SEVEN(0.00)[7]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[grog@FreeBSD.org,grog@lemis.com]; RCVD_NO_TLS_LAST(0.10)[]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:20473, ipnet:45.32.64.0/19, country:US]; FROM_NEQ_ENVFROM(0.00)[grog@FreeBSD.org,grog@lemis.com]; MAILMAN_DEST(0.00)[ports] 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: Sat, 29 Aug 2020 23:27:15 -0000 --DIOMP1UsTsWJauNi Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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.=A0 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.=A0 -fno-common is the new >> 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, 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@. 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 --DIOMP1UsTsWJauNi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAl9K5EsACgkQIubykFB6QiP/XACfTU1l6Hjt+ziBm57JiceidlTc hFQAoIvOq2RtBfeJEC6iaSSOKhyzTem2 =fzGb -----END PGP SIGNATURE----- --DIOMP1UsTsWJauNi--