From nobody Wed Feb 28 21:27:05 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 4TlS9W19WMz5CRcx for ; Wed, 28 Feb 2024 21:27:11 +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 4TlS9W038lz4dq4; Wed, 28 Feb 2024 21:27:11 +0000 (UTC) (envelope-from flo@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1709155631; 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: in-reply-to:in-reply-to:references:references; bh=OXPJZtK298pAXJzQVZJVO5WlqzjCGx8/Pddmc3B0gB0=; b=u7U1sOu7znMh8aNsJ1OGO54SaiRMQxjnKC+N2yDmEA2k6jQ+I5U4L3EKt6i3h2nMYd3d6w 8/9WUkW62BlESMMG6G2Fw1/nb5sKh9gFJHrx2aLw0dk2dkSrLuXQsfP83rbELdKmI+MM5q ilFpbZYCWLg11+ulTX/902ngNNvdFk4EysOduuHkNFCvN8Ox9ExHbDXOoJPw7VzDx2JCsx Gs8iW6rbPf4qiDUTreDb9x3OMGItrl+jDdn8wOzgwMc0vgb8W/oI6YqDnryFF6gELyCPEj S3qNFhZXSJNwIM2We7BSKdZxOFcoy3Vt15B9DTWwSq13rCmsCXOyS1+1pCzxuQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1709155631; a=rsa-sha256; cv=none; b=dXCeGlPnF8N4nRWlRVezbUvzvAQwtS/l606yltW77m3KVaZdsah3fRUUzxdSIt6dGm5KyO RPe5EMJ9K32+0/EyM+WVkHn1I1JqspBV/pIBI1Cxi2sCQUA70opaVR9xUobLqDZblu20gb LPxPcxaGnv2TOHQ2MQjoG96oU3o0bWiu3XR4M33SdUHZuh5xtFPQDcVb3Mx3bW94PYVNtv gGFep73euloTytBVfHXAZUk1zxWCiRktJ2l/HpluwPzU7zBK0i/C0MGK5qSbs0peCGrZE6 kzqKVzqV2U1aw1L44um4qf/bBRyjBuzuqsGV+xyUKpvaGjzmSq1eY7CK37/mhw== 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=1709155631; 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: in-reply-to:in-reply-to:references:references; bh=OXPJZtK298pAXJzQVZJVO5WlqzjCGx8/Pddmc3B0gB0=; b=cfLOPfV3E7LX8gXf/0lwv6fgcOzqICLv4xDZmYEH6IdDWKmCqfrGWE6xN1Fs8QTcFt/vKL Zc7GrvWpZBVd3RLN3q+Bxtd9CBgvb/af5lpmqnjQNkXk6J5HvhXdSpT9xTZxsTxK0aerAD xt7nFPOJ+l0TNpfC8hw8kdigYv4uLG1wVJaHwn+C8I/enSaBeHhHcTG3ttMnRr4HhVkYd5 ZP0Bc2m0SEdcASMOIFPUKJMmaIO7L9Z49rMlhiTGEVfuHJ6IlbPd4g73/qX4XPXCwv7F28 UixWiQi/OjQ+QdvDSFlpaBd5WoWphh5cIKsfWWt1B3Gm4sfRua5R/1tyOigLlQ== 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 4TlS9S6nbqz1K4W; Wed, 28 Feb 2024 21:27:08 +0000 (UTC) (envelope-from flo@FreeBSD.org) Message-ID: <9f0610d5-c999-4b39-9175-d9a54ad0a9f1@FreeBSD.org> Date: Wed, 28 Feb 2024 22:27:05 +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: Charlie Li , ports@freebsd.org References: <435edf7c-a956-4317-b327-3372de70dbef@FreeBSD.org> <6d0a6af4-01d8-4db9-9661-ce688dc8da03@freebsd.org> From: Florian Smeets In-Reply-To: <6d0a6af4-01d8-4db9-9661-ce688dc8da03@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 28.02.24 22:09, Charlie Li wrote: > Florian Smeets wrote: >> 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. >> > The phrasing "blocks progress" is problematic. Progress of what? > Indiscriminately hunting down EOL/apparently inactive software? Mass > migrating from one build system to another due to primarily personal > preference, even against upstreams' will? This phrasing is vague enough > to justify deprecating and removing, say EOL (but still fetchable and > buildable) libraries needed by actively-maintained and supported (and > popular) software that are in no rush to migrate away. If this vagueness > is intended, then it needs to be accompanied with *us* actively > developing in the upstream project to support efforts here. The sentence you refer to is just a rough summary of what is described in more detail further down. e.g. >> - 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 >> > These reasons are good on first read but the premise needs to be worked > in earlier. Also need to consider actively-maintained and supported > software that happen to use EOL dependencies. > I don't understand what you are trying to say with the first sentence. It's kind of implicit that we will not allow removal of libraries that still have (lots of) ports depending on them with this policy. But we should probably make this explicit. I'll add a note and come up with something. Thanks Florian