From nobody Wed Feb 28 22:13:08 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 4TlTBb3L74z5CWG1 for ; Wed, 28 Feb 2024 22:13:11 +0000 (UTC) (envelope-from flo@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4TlTBb2dRjz4kvX; Wed, 28 Feb 2024 22:13:11 +0000 (UTC) (envelope-from flo@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1709158391; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kjtU46NYFRb1FFyz/bWEgEs9vc73L8POqK7TCj61Ymc=; b=mxq7L/iS/DhRNcKnAD42pnZ3pveR3kB492gARs9qAfCNYPQeoqRfBl37soLT+MVFewPiHU 60fdMTkUlxMfpKJ/8pSFMbUpbOLoNxDGBhqOM5gIac0cSclAO9mzp6XonKgelathxd/crQ SM6FuC9gC/6NtbPh+FBzIPfHHqLVKIo3iWAk/UdM4ClhdwioyBCEOAnCDTZ/TogLEzkFpE LuJHSKgCPHgvIc1IUONeOK+IG8ZK0QE9+WhiIA0aAimpQYn8GJS2tpmaSSHYl5jBTCc9xF QkTR/B4i5CHfCFhWNlbrmRlr7Lp2CBH0kwa0L6CivfCU9Zs47/iuRuI3IobAYg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1709158391; a=rsa-sha256; cv=none; b=dTacAlb2zs0x2HMhQKOHPJxDPpkULdWiCOnuZuWDkWWvNsOzAzoLwsv1fo6b5qA0Ae8zUY +qa3WMIPO5eKNm2JnlGM5mnvv7nyUFJhPfA3yxt7SNVztdNH6b5/lYgIZMLJ4FEdsRfcED 8AmdIV5VZLSxB+6u+5yzjU3a9b55HFB54SXNJGr43iqshhauosPstdFlMliRIBGITmuY/g EF44jArRvY2bZD8LYJ/J8xh4vBPsoXh6pmcHg/OdhmanEjvxuKLA3l96wHpIlrq1CpESh5 HWxRl6LS9H0RDW83gbE/f50wj2EnbyfQCjuLYm55ouyFO74LuZXqEHCGFpH09A== 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=1709158391; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kjtU46NYFRb1FFyz/bWEgEs9vc73L8POqK7TCj61Ymc=; b=g6C05ogNtXTG77ibtGKcTyODAbG/WTE54i2CAR2sBndw9RSrcr4NBCRX8Rm7TIoS3oFapE OkriBFe1cSFMM6oPBxxps6txZLgQRxareXK1acfaiu4syLfy07rAaLAR1PdRFH177nU1Ly NA1v39TgiWFrOIt0M0DOKsyJVPlMZU+5FzOaPo4yLEIIG6OI8k9Bmu8dap4L2v2aOK+SOt Yo1mgh/pXQtbrICEYtvhEUJIo42AMuHPZxm31MdxSahKpfLUg0McC8RK9VuiZqhBijDFOX 8kFA7pbVLSmm+I2eABTzOBoQIwaHZmBFAe8BzR3JiDJSL/AofZ9nK/aCdAqW0g== 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 4TlTBZ2hJbz1KKl; Wed, 28 Feb 2024 22:13:10 +0000 (UTC) (envelope-from flo@FreeBSD.org) Message-ID: Date: Wed, 28 Feb 2024 23:13:08 +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 Subject: Re: Proposed ports deprecation and removal policy Content-Language: en-US To: Michael Gmelin Cc: ports@freebsd.org References: <435edf7c-a956-4317-b327-3372de70dbef@FreeBSD.org> <817F1C79-001F-4131-BC54-A992BA1B78D0@freebsd.org> From: Florian Smeets In-Reply-To: <817F1C79-001F-4131-BC54-A992BA1B78D0@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 28.02.24 22:18, Michael Gmelin wrote: > > >> On 28. Feb 2024, at 20:22, Florian Smeets wrote: > > Hi Flo, > > Thanks for the effort, it’s a delicate topic for many. It is, we're tying our best and put some thought into it in the last coupe of weeks. > >> 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: >> > > By whom though? Portmgr? Any committer? Yes, this is a tough one. Obviously, first it's the maintainers job. If it's broken, vulnerable, etc. anybody can set DEPRECATED and remove it once it expires. How I saw this policy while writing it was as a guideline for maintainers and committers. Not something to allow committers to remove stuff at will that might fall under one of these points. But it will certainly be used to justify the start of glib20 deprecation and subsequent removal, for example. But that is a topic for another day ;) > >> - 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. > > How many ports in the tree would be affected by this policy at the moment? Honestly, I don't know. I'm not on a witch hunt for them. The policy is looking to make it easier to remove old stuff that hinders progress. If it's actively maintained, builds and is not vulnerable there should not be an issue. We are trying to make ports a bit more sustainable with the resources we have. e.g. look at the last PRs for the clang/LLVM updates. > > Does “EOL versions“ also affect software where there are no new versions available (like, development officially stopped a long time ago or there was a license change, the project was archived etc.), or just outdated versions of software that is still under development? In any case, three months seems relatively short. > > I’m maintaining a couple of ports where upstream officially stopped development, but which are still super useful (so they’re not just part of my personal software museum/there for sentimental reasons). That is why we have lots of shoulds in the policy. Some of the policies might have been written with server software in mind too much that have different versions in parallel. e.g. PHP, asterisk, etc. And yes, ports remaining or becoming more of a software museum is one of the things we want to combat with the policy to become more sustainable. Florian