From nobody Wed Feb 28 21:18:53 2024 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TlS0836Ptz5CRN4 for ; Wed, 28 Feb 2024 21:19:04 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TlS0765zTz4cRN; Wed, 28 Feb 2024 21:19:03 +0000 (UTC) (envelope-from grembo@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 649ef09a; Wed, 28 Feb 2024 21:18:55 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 1da66e87 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 28 Feb 2024 21:18:55 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: Proposed ports deprecation and removal policy From: Michael Gmelin In-Reply-To: <435edf7c-a956-4317-b327-3372de70dbef@FreeBSD.org> Date: Wed, 28 Feb 2024 22:18:53 +0100 Cc: ports@freebsd.org Message-Id: <817F1C79-001F-4131-BC54-A992BA1B78D0@freebsd.org> References: <435edf7c-a956-4317-b327-3372de70dbef@FreeBSD.org> To: Florian Smeets X-Mailer: iPhone Mail (20H307) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE] X-Rspamd-Queue-Id: 4TlS0765zTz4cRN > On 28. Feb 2024, at 20:22, Florian Smeets wrote: >=20 > =EF=BB=BFDear ports community, >=20 > as the removal of ports is a recurring source of friction and dispute we w= ould like to add a ports removal and deprecation policy to the porters handb= ook. >=20 > We tried to find a sensible middle ground between too fast removal and kee= ping unmaintained and abandoned upstream software in our ports tree forever.= >=20 > When can or should ports be deprecated or removed? >=20 > This policy should give some guidance on when ports can or should be remov= ed. In general ports should not be removed without reason but if a port bloc= ks 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 c= an be made. For more details see below. >=20 >=20 Hi Flo, Thanks for the effort, it=E2=80=99s a delicate topic for many. > Ports can be removed immediately if one of the following conditions is met= : >=20 > - Upstream distfile is no longer available from the original source/mirror= (Our and other distcaches e.g. Debian, Gentoo, etc do not count as "availab= le") > - Upstream WWW is unavailable: deprecate, remove after 3 months > - BROKEN for more than 6 months > - has known vulnerabilities that weren=E2=80=99t addressed in the ports tr= ee for more than 3 months >=20 >=20 > A port can be deprecated and subsequently removed if: >=20 By whom though? Portmgr? Any committer? > - Upstream declared the version EOL or officially stopped development. DEP= RECATED 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. O= ption two is *not* possible without backporting patches, see vulnerable port= s) The general suggestion is that EOL versions should not stay in the ports t= ree for more than 3 months without justification. How many ports in the tree would be affected by this policy at the moment? Does =E2=80=9CEOL versions=E2=80=9C also affect software where there are no n= ew versions available (like, development officially stopped a long time ago o= r there was a license change, the project was archived etc.), or just outdat= ed versions of software that is still under development? In any case, three m= onths seems relatively short. I=E2=80=99m maintaining a couple of ports where upstream officially stopped d= evelopment, but which are still super useful (so they=E2=80=99re not just pa= rt of my personal software museum/there for sentimental reasons). Best > - The port does not adapt to infrastructure changes (i.e. USE_STAGE, MANPR= EFIX, compiler updates, etc.) within 6 months. Ports should be set to DEPREC= ATED after 3 months and can be removed after 6 >=20 >=20 > Reasons that do not warrant removal of a port: >=20 > - Software hasn=E2=80=99t seen a release in a long time > - Upstream looks inactive for a long time >=20 > Florian (on behalf of portmgr)