Just a disclaimer: I’m speaking for myself here, not on behalf of portmgr@. Also please keep in mind that I am perpetually, pathologically optimistic.
> On Aug 29, 2020, at 18:01, Warner Losh <i...@bsdimp.com> wrote: > >> On Sat, Aug 29, 2020, 5:27 PM Greg 'groggy' Lehey <g...@freebsd.org> 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. >> >> 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. 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 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@. > > > This is a bad idea. It disempowers the community of ports developers and > contributors. I agree 100% with Warner here. I think what we’ve seen here is the system working exactly the way it’s supposed to: a committer uses his or her judgment, others disagree and start a discussion, and changes are made. It doesn’t mean that we should take autonomy away, and I will always come down on the side of trusting committers to DTRT. Quarterly branches let us have these sorts of discussions and support the process, because nothing in latest is set in stone (though I’d strongly urge people to avoid making any significant changes in the two weeks before a branch point). I’d be in support of making the actual removal of expired ports the purview of portmgr (René has been so on top of this, I think we’re going to have to staple him to his keyboard and never let him leave), but I’d 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. > > > We had this attitude in the base towards drivers. It held us back all for the > sake of hardware that netted us few, if any, users. I fear the same will > result if we did this. I understand the point being made here, and the problem is that we abuse the BROKEN variable. Ports that don’t adapt aren’t necessarily broken (unless they no longer build and are actually broken). We have a habit of using BROKEN to mean “someone should take a look at this.” Perhaps we need a better way of signifying this. In the end, though, if nobody cares enough about a port to fix it, it is reasonable to remove it (I believe it is Baptiste who says “the ports tree is not a museum”). >> 3. Ports should not be removed without community consultation, which >> should last for at least n months, with m reminders being sent. > > > This is overkill. It was recommended for the driver removal and I said no > after trying it a couple of times. After a while they are ignored. We had > super poor response after the first warning, and none after the second. > > You are better off deprecating a bunch of ports that aren't maintained. And > then warning the users every time they boot and/or pkg upgrade. Ideally you'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 > course on), but we've had few complaints for the ones actually removed. > > If no one is even signed up to maintain it, then it's a crapshoot for our > users that try to use it. If people are using it, one of them can sign up to > get problem reports on it. If interest in the port doesn't rise to even that > low level of commitment, then we should remove it as uninteresting. In this > round of chaos, we'd also have 200 or so people sending in tested changes > rather than having to have someone grind through them all. And we'd also know > who can't be bothered. > > Each additional port isn't free. You have to spend cycles building it. Cycles > looking at it should the compiler change, etc. The cumulative effect gets too > large even if each individual port isn't too bad. > > Basically, it draws the community back in, even if it's just small ways, > rather than having them be a pure consumer giving nothing back. Make it easy > to adopt a port, and we'll grow our base of labor. Make it easy to remove > ports that no one can be bothered to adopt and we shrink our workload. And > we'll spend our time on the things that we know net us at least one user who > will pledge to keep it going. This is a serious issue that we’ve been dealing with for a long time. I’ve advocated very strongly for a script that automatically notifies the maintainer (+/- ports@?) when a port is marked BROKEN and/or DEPRECATED. Community notification is always a good thing, and it opens the door for objections and discussion. Nobody has written such a script, but I would be thrilled to help deploy such a script if someone writes it. # Adam — Adam Weinberger ad...@adamw.org https://www.adamw.org _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
