Date: Wed, 28 Feb 2024 16:12:13 -0700 From: "Edward Sanford Sutton, III" <mirror176@hotmail.com> To: ports@freebsd.org Subject: Re: Proposed ports deprecation and removal policy Message-ID: <CO1PR11MB47704367D666EFFB003CE07FE6582@CO1PR11MB4770.namprd11.prod.outlook.com> In-Reply-To: <435edf7c-a956-4317-b327-3372de70dbef@FreeBSD.org> References: <435edf7c-a956-4317-b327-3372de70dbef@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/28/24 12:22, Florian Smeets wrote: > Dear ports community, > > as the removal of ports is a recurring source of friction and dispute we > would like to add a ports removal and deprecation policy to the porters > handbook. If it is clear that guidelines could be interrupted/altered as discussion opens up and that it isn't necessarily a set in stone process as a result, it can put people's mind at ease that efforts are being organized instead of people are just trying to stomp out things in a quick and concise manner at the first justifiable chance. I have and still use a python2 dependent program that is so niche that I never saw it hit the ports tree (and didn't like my own porting effort's results). I have not yet successfully migrated to a non python2 solution successfully; I lost all upstream support as others moved on to new shiny things which I hope to do someday but they aren't direct replacements. Obviously no one would keep python2 in ports for my case then, but I did benefit from others having reasons that kept it there. I also know that without, I could setup an old ports tree, and package lock/jail/virtual machine my way through the problem. Watching the python2 deprecation/removals kick into gear felt like a weird clash between maintainer and user community. Looking back, I wonder if a different solution of 'let someone else become maintainer' may have been better since it was being triggered by an EOL instead of vulnerabilities and broken builds. Can EOL upstream case be clarified for when an upstream is required and what meets said upstream? Some upstreams don't accept patches and others seem to only fix things based on outside submitted patches. That seems to blur the lines between upstream, community, and port maintainer for who can do things. I figure my more extreme example above of python2 had a fight that EOL was important as vulnerabilities were common enough and project was big enough that 1 or a few people would not be able to guarantee a safe+working state; As safe is 'never' guaranteed anyways which makes it more confusing there. I forgot to mention it, but am still thankful for all who make the ports tree happen: maintainers, users who submit PRs with/without patches, general committers, and those who organize all of this structure and flow. Though not perfect, all of that effort has lead to making it a generally great experience over the years that I have used it. > We tried to find a sensible middle ground between too fast removal and > keeping unmaintained and abandoned upstream software in our ports tree > forever. > > When can or should ports be deprecated or removed? > > This policy should give some guidance on when ports can or should be > removed. In general ports should not be removed without reason but if a > port blocks progress it should be deprecated and subsequently removed. > In general, if a ports blocks progress for some time it will be removed > so that progress can be made. For more details see below. > > > Ports can be removed immediately if one of the following conditions is met: > > - Upstream distfile is no longer available from the original > source/mirror (Our and other distcaches e.g. Debian, Gentoo, etc do not > count as "available") > - Upstream WWW is unavailable: deprecate, remove after 3 months > - BROKEN for more than 6 months > - has known vulnerabilities that weren’t addressed in the ports tree for > more than 3 months > > > A port can be deprecated and subsequently removed if: > > - Upstream declared the version EOL or officially stopped development. > DEPRECATED should be set as soon as the planned removal date is know. > (It is up to the maintainer if they want to remove the port immediately > after the EOL date or if they want keep the port for some time with > backported patches. Option two is *not* possible without backporting > patches, see vulnerable ports) The general suggestion is that EOL > versions should not stay in the ports tree for more than 3 months > without justification. > - The port does not adapt to infrastructure changes (i.e. USE_STAGE, > MANPREFIX, compiler updates, etc.) within 6 months. Ports should be set > to DEPRECATED after 3 months and can be removed after 6 > > > Reasons that do not warrant removal of a port: > > - Software hasn’t seen a release in a long time > - Upstream looks inactive for a long time > > Florian (on behalf of portmgr) >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CO1PR11MB47704367D666EFFB003CE07FE6582>