From owner-freebsd-ports@freebsd.org Sun Aug 30 00:50:27 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 4B48D3C2E2B for ; Sun, 30 Aug 2020 00:50:27 +0000 (UTC) (envelope-from adamw@adamw.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BfF9v0Nmhz4KDt for ; Sun, 30 Aug 2020 00:50:27 +0000 (UTC) (envelope-from adamw@adamw.org) Received: by mailman.nyi.freebsd.org (Postfix) id 0B80D3C300C; Sun, 30 Aug 2020 00:50:27 +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 0B3F53C3101 for ; Sun, 30 Aug 2020 00:50:27 +0000 (UTC) (envelope-from adamw@adamw.org) Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BfF9s50jCz4KKK for ; Sun, 30 Aug 2020 00:50:25 +0000 (UTC) (envelope-from adamw@adamw.org) Received: by mail-io1-xd41.google.com with SMTP id g14so2750173iom.0 for ; Sat, 29 Aug 2020 17:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adamw-org.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Rd/DhKg1HuwtcWAg+z7/A1nU6KvrXkCN5PPkfd9OAQg=; b=KDc/lSSUVCSNbDlYRUyax+m0jZkoxVlwz38o4MUbOaAxkPVtOuaEzOP2lVA9be6zBm rkFNntPJUaHzcxFRJC7ywt2GL5ung4jsiRMEa7FjuA3Za7nsnjE0ZeAjU9Rvr4WirEkb ks0AcUdk+dhZK1q3xx3q2/YSqLAVYm6RyJoQgm8i3a5YTvWP1cDlLvvUeFUm4nBGO1ki ezCgHLJLPhxRcfjPQeASE5OXHjBfoxW0D6qmK8tiBEZqaH7mRkOCB6ILFBKQtwJlxQvG pjFZs8+UQioERhHQ3qHnzTDL2jW5ii1641V0vm2uw1t7a9YdKceScMH6yIXcFKU34iGZ SnUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Rd/DhKg1HuwtcWAg+z7/A1nU6KvrXkCN5PPkfd9OAQg=; b=dDMEWiRLtBoJcm4QWa6GYDuXWnUgs6WYI90wb5xx6QbXm+UmUxEWL90GWPf1WIxZN2 UOauN1GxCnYdCBlV6igZQv14KsgGJKTln1CWtGiYi1AI3lwEJDSRFiRYBQDLCvPsTn0l c8NoaokBfYx9s99mT/NMTMs3YqXzkJwhtwSYtmfkj10PEPsrnNdOD2D0xynuuETHuFUi rd2d2whp9h3MnkKBkzcMkDW+CUbrSvLhvcOGeyxCO6M0tuaPTrECbJQQKb6BRwhslXUs iNwDQ5I/RMbq31ndtXRVTtiKwK8ufvMAZkyjuKTzuBTD1K/at1pVGqmCNGiVY9vXMksu CEaQ== X-Gm-Message-State: AOAM5310HxcK6veiGpZdFULsGYS5XhUFxfrVhAgT5wSKaGc5lCfK+uET eQYee9PJ212rjZUAOieeFelong== X-Google-Smtp-Source: ABdhPJyITc9ev1OyB/LAis0zJiz2WZrSwZ4CxFpanc91yhjZ3DD1CQ8/lxdkINgeQ8wqeH2a1AnDPg== X-Received: by 2002:a6b:600a:: with SMTP id r10mr4040399iog.0.1598748624125; Sat, 29 Aug 2020 17:50:24 -0700 (PDT) Received: from ?IPv6:2601:8c3:8100:160f:8929:68ed:e6d8:b045? ([2601:8c3:8100:160f:8929:68ed:e6d8:b045]) by smtp.gmail.com with ESMTPSA id 187sm1881146iow.34.2020.08.29.17.50.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Aug 2020 17:50:23 -0700 (PDT) From: Adam Weinberger Mime-Version: 1.0 (1.0) Subject: Re: Aggressive ports removal (was: svn commit: r546907 - head/x11-clocks/wmtime) Date: Sat, 29 Aug 2020 18:50:22 -0600 Message-Id: <4F34C480-63D3-48C4-9747-FDA1E5D66507@adamw.org> References: Cc: Greg 'groggy' Lehey , Stefan Esser , Niclas Zeising , Michael Gmelin , FreeBSD Developers , tcberner@freebsd.org, ports@freebsd.org, portmgr@freebsd.org In-Reply-To: To: Warner Losh X-Mailer: iPad Mail (17G80) X-Rspamd-Queue-Id: 4BfF9s50jCz4KKK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=adamw-org.20150623.gappssmtp.com header.s=20150623 header.b=KDc/lSSU; dmarc=none; spf=pass (mx1.freebsd.org: domain of adamw@adamw.org designates 2607:f8b0:4864:20::d41 as permitted sender) smtp.mailfrom=adamw@adamw.org X-Spamd-Result: default: False [-3.68 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[adamw-org.20150623.gappssmtp.com:s=20150623]; FREEFALL_USER(0.00)[adamw]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[ports@freebsd.org]; DMARC_NA(0.00)[adamw.org]; MID_RHS_MATCH_FROM(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.986]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[adamw-org.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.67)[-1.672]; RCPT_COUNT_SEVEN(0.00)[9]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d41:from]; NEURAL_HAM_MEDIUM(-1.02)[-1.020]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[ports] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 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 00:50:27 -0000 Just a disclaimer: I=E2=80=99m speaking for myself here, not on behalf of po= rtmgr@. Also please keep in mind that I am perpetually, pathologically optim= istic. > On Aug 29, 2020, at 18:01, Warner Losh wrote: >=20 >> On Sat, Aug 29, 2020, 5:27 PM Greg 'groggy' Lehey wrot= e: >> 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 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 broke= n >> >> 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 P= R >> >> 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? >>=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. >>=20 >> My suggestion: >>=20 >> 1. Decisions to deprecate remove ports should be made only by >> portmgr@. >=20 >=20 > This is a bad idea. It disempowers the community of ports developers and c= ontributors.=20 I agree 100% with Warner here. I think what we=E2=80=99ve seen here is the s= ystem working exactly the way it=E2=80=99s supposed to: a committer uses his= or her judgment, others disagree and start a discussion, and changes are ma= de. It doesn=E2=80=99t mean that we should take autonomy away, and I will al= ways come down on the side of trusting committers to DTRT. Quarterly branches let us have these sorts of discussions and support the pr= ocess, because nothing in latest is set in stone (though I=E2=80=99d strongl= y urge people to avoid making any significant changes in the two weeks befor= e a branch point). I=E2=80=99d be in support of making the actual removal of expired ports the p= urview of portmgr (Ren=C3=A9 has been so on top of this, I think we=E2=80=99= re going to have to staple him to his keyboard and never let him leave), but= I=E2=80=99d prefer to leave the deprecation decision up to the team. >> 2. Ports are not broken because they don't easily adapt to some new >> ports framework. >=20 >=20 > We had this attitude in the base towards drivers. It held us back all for t= he sake of hardware that netted us few, if any, users. I fear the same will r= esult if we did this. I understand the point being made here, and the problem is that we abuse the= BROKEN variable. Ports that don=E2=80=99t adapt aren=E2=80=99t necessarily b= roken (unless they no longer build and are actually broken). We have a habit= of using BROKEN to mean =E2=80=9Csomeone should take a look at this.=E2=80=9D= Perhaps we need a better way of signifying this. In the end, though, if nob= ody cares enough about a port to fix it, it is reasonable to remove it (I be= lieve it is Baptiste who says =E2=80=9Cthe ports tree is not a museum=E2=80=9D= ). >> 3. Ports should not be removed without community consultation, which >> should last for at least n months, with m reminders being sent. >=20 >=20 > This is overkill. It was recommended for the driver removal and I said no a= fter trying it a couple of times. After a while they are ignored. We had sup= er poor response after the first warning, and none after the second.=20 >=20 > You are better off deprecating a bunch of ports that aren't maintained. An= d then warning the users every time they boot and/or pkg upgrade. Ideally yo= u'd do it at use, but that is hard. For drivers, we added a whine at attach.= There were a couple people complained about after (one that we reversed cou= rse on), but we've had few complaints for the ones actually removed. >=20 > If no one is even signed up to maintain it, then it's a crapshoot for our u= sers that try to use it. If people are using it, one of them can sign up to g= et problem reports on it. If interest in the port doesn't rise to even that l= ow level of commitment, then we should remove it as uninteresting. In this r= ound of chaos, we'd also have 200 or so people sending in tested changes rat= her than having to have someone grind through them all. And we'd also know w= ho can't be bothered.=20 >=20 > Each additional port isn't free. You have to spend cycles building it. Cyc= les looking at it should the compiler change, etc. The cumulative effect get= s too large even if each individual port isn't too bad. >=20 > Basically, it draws the community back in, even if it's just small ways, r= ather than having them be a pure consumer giving nothing back. Make it easy t= o adopt a port, and we'll grow our base of labor. Make it easy to remove por= ts that no one can be bothered to adopt and we shrink our workload. And we'l= l spend our time on the things that we know net us at least one user who wil= l pledge to keep it going. This is a serious issue that we=E2=80=99ve been dealing with for a long time= . I=E2=80=99ve advocated very strongly for a script that automatically notif= ies the maintainer (+/- ports@?) when a port is marked BROKEN and/or DEPRECA= TED. Community notification is always a good thing, and it opens the door fo= r objections and discussion. Nobody has written such a script, but I would b= e thrilled to help deploy such a script if someone writes it. # Adam =E2=80=94 Adam Weinberger adamw@adamw.org https://www.adamw.org