Date: Wed, 28 Feb 2024 15:38:55 -0700 From: "Edward Sanford Sutton, III" <mirror176@hotmail.com> To: ports@freebsd.org Subject: Re: Proposed ports deprecation and removal policy Message-ID: <CO1PR11MB47706AC0A06D7108F70A55C2E6582@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. > > We tried to find a sensible middle ground between too fast removal and > keeping unmaintained and abandoned upstream software in our ports tree > forever. Not otherwise mentioned in this post, there is value in considering the difference between unmaintained upstream, unmaintained from an inactive port maintainer, unmaintained from an interested port maintainer that is unable to solve the problems they have been presented with or find helpers who did, and unmaintained due to no maintainer for the port. Is there a recommendation, and way to go about it, for port maintainers to preemptively mention extended away time like vacation/holiday or longer? > 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. I presume 'progress' means things like 'blocks ports framework updates' as cases were mentioned of later, but was this the intent? Removing a port that causes conflict building/installing another could be considered progress. > 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 As some ports don't really have a WWW this may be a bit harsh in special cases where community interaction beyond source code is through a mailing list, chatroom, discord, etc. Some websites may be neglected or left to expire due to little interest from who ran it even though a project isn't similarly dead. > - BROKEN for more than 6 months Presume this is a 'broken for everyone on supported FreeBSD releases' though should probably also include stable and current before deletion can happen. I have seen results, besides just a 'BROKEN' being set, from ports with maintainers that had a PR with a maintainer's patch that fixed a problem go for months without being committed. I hope a rush to mark/remove ports as this email implies would lead to more efficient flow rather than creating more work by actions that would be a mistake in such cases. > - has known vulnerabilities that weren’t addressed in the ports tree for > more than 3 months Will the scope of a vulnerability be considered? As an example, removing virtualbox because of a network vulnerability means users who do not need such capability lost the port too. Trying to follow CVEs has made it clear to me that some end up being bugs or possibly unexpected program operation that doesn't seem to have any known example of how the bug is even a security issue. > 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. Are we thinking of 'old version' cases such as python27, or even cases where upstream EOL'd the project as a whole? Would it be handled differently if an alternative exists or not and if an alternative community can be switched to for further project coordination? > - 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 Some ports are not hier compatible in general even though they are still useful ports. How are exceptions to be decided? Are they marked as an exception in the Makefile? > 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) No maintainer + no upstream maintenance when issues have arisen (security, build, infrastructure compatibility) seems like a good time for marking for removal as a general concept though it seems many ports I use, or just try out, regularly don't have maintainers. As issues arise, people often step up and report them or fix them as nonmaintainer which then get committed. I feel I'm not the best choice for maintainer as I am not active enough and often find I go periods where I don't pay active attention; my email often goes through phases where it doesn't get looked at if I'm not actively looking for something. I also found through experience that simple porting problems often go beyond my abilities. Some ports would likely benefit from just having a maintainer as someone who coordinates the effort to keep it working even creating the port+patches is beyond them. This could be a point of failure if they recommend submitted patches be committed without requesting outside help reviewing them such as for safety. Could we document more clearly if such a maintainer is desired and if it is, even recommend it in the all-too-common 'this port has no maintainer' messages? Similarly, pkg could really benefit from listing that message once with a list of ports it applies to as I find the messages basically just become noise at this point.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CO1PR11MB47706AC0A06D7108F70A55C2E6582>