From nobody Wed Feb 28 19:22:34 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 4TlPPq55Kzz5CHL3 for ; Wed, 28 Feb 2024 19:22:39 +0000 (UTC) (envelope-from flo@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TlPPq4dNcz4Njn; Wed, 28 Feb 2024 19:22:39 +0000 (UTC) (envelope-from flo@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1709148159; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Yxct7+m1BHl06R8J3SeG2Ms+cqv9iPP7qnaHOGfTSew=; b=TFGMaULUB02YWArlOUhxCiqHLv2aC8owrU6gEQ2uEo8YVkU7DshBXQatdZono2o92Ga0kv iKsPbbzCiAyAGo4o8pWk4AwuZhVqYzfcAr2VdByi3zwtPwln/K1WU7jgcNo9Zbdpop/Zz8 06rMiOYV22cwaECTG8LN/Nx5YGPGnRO1jY25jG7PFEGJdR3x9S4omlcudk1ISiTfoQ4Ekg h2J5EQme3GHxwtWoZ/c1X7c1CMnrU8pO/yJDA7V4s1rJ33nWgKovhwRdxvHctaGAiOIL0O q9/BvxYizJNcxayxeZOjiZ+vf4Nq5VPkiUlOuuPMUNifFCMFcjNN+xfqfbQKAg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1709148159; a=rsa-sha256; cv=none; b=Ve003n+E6CDxbiQK2RM5ptaa3khToxkgZ8fozKMw7sB8XBZcl4vZa83rbOzrLRlUfme3jk icJdz3FYWqC5wuHwyREgQX07qiwHo2biDX8MXs7hYCGHTuuchAOFpaWlxYBi/+4ntpXWmM F6fn8RPWWfIZF3VCRBDkMwnfgKxEjJdxntf0UTVo2uoWFeIdz7t7TBOACLr/EtZ+QrAth/ marOeAqdTLWJqgI1HVRQc4hzM8Xu5KXxKbheB0Ci5lDx47RFb8nWAb4LamqYxblD75T/mo tCXD5Lrv4D9udD/A6/kVW265jy4kQPWC5rMToiLD35TvWJZ0NbczfdqC4B41og== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1709148159; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Yxct7+m1BHl06R8J3SeG2Ms+cqv9iPP7qnaHOGfTSew=; b=xEM3k7g61sbQHxYEzRrOLXQOdlVrzwiC1vUEEGlQoa1/YIvNsBXJAlHfW09GbzMfF4md+h q544xAu9AE2L7sU2X2kn7ZqU68NT0Bu8M/7AoLQvttQkcbS4Tk/RdlgKt8GKXd/QksUMbp vcpkuQX+fI3AR9xTS3Sc6wGPU0Mlh97w4fms+jxUOikFHdNjt/VhrBH03Ms6EySJMily/P 40KkOdVNAJQfl3npbgWCqT4harEr2izVepbaxZ2mclyt6JUl0Jkz/FERYc6zziy4Ju8Tij icQnLDJQRGIIWkZ5PVQNoY3a6InZh0x54q2lNrbTUwmqAJf7MjgsFAC7A+m+jg== Received: from [IPV6:2a01:4f8:10a:fd43::dead] (unknown [IPv6:2a01:4f8:10a:fd43::dead]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: flo/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TlPPp6LSQz1GRd; Wed, 28 Feb 2024 19:22:38 +0000 (UTC) (envelope-from flo@FreeBSD.org) Message-ID: <435edf7c-a956-4317-b327-3372de70dbef@FreeBSD.org> Date: Wed, 28 Feb 2024 20:22:34 +0100 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 User-Agent: Mozilla Thunderbird From: Florian Smeets To: ports@freebsd.org Content-Language: en-US Subject: Proposed ports deprecation and removal policy Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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. 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)