Date: Sat, 29 Aug 2020 18:50:22 -0600 From: Adam Weinberger <adamw@adamw.org> To: Warner Losh <imp@bsdimp.com> Cc: Greg 'groggy' Lehey <grog@freebsd.org>, Stefan Esser <se@freebsd.org>, Niclas Zeising <zeising@freebsd.org>, Michael Gmelin <grembo@freebsd.org>, FreeBSD Developers <developers@freebsd.org>, tcberner@freebsd.org, ports@freebsd.org, portmgr@freebsd.org Subject: Re: Aggressive ports removal (was: svn commit: r546907 - head/x11-clocks/wmtime) Message-ID: <4F34C480-63D3-48C4-9747-FDA1E5D66507@adamw.org> In-Reply-To: <CANCZdfpWaib-h3fVJKbrL5L5sHJQLj6UcQAcsGcH4cBtf53YRQ@mail.gmail.com> References: <CANCZdfpWaib-h3fVJKbrL5L5sHJQLj6UcQAcsGcH4cBtf53YRQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <imp@bsdimp.com> wrote: >=20 >> On Sat, Aug 29, 2020, 5:27 PM Greg 'groggy' Lehey <grog@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F34C480-63D3-48C4-9747-FDA1E5D66507>