From nobody Thu Feb 29 19:26:23 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 4Tm1Ry5Rgdz5Cm7C for ; Thu, 29 Feb 2024 19:26:38 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Tm1Rx6s1Rz4YYt; Thu, 29 Feb 2024 19:26:37 +0000 (UTC) (envelope-from delphij@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZxZ4BK9k; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of delphij@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=delphij@gmail.com Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a3ed9cae56fso467207966b.1; Thu, 29 Feb 2024 11:26:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709234795; x=1709839595; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gqpC0LLsZAmk4obVOmg1LEqeGNecCiDiiC5C0BIjtcY=; b=ZxZ4BK9ktSkUU5+M39m1GSog2ls7uiu8FWG8g3dnQdC9umDYD4BMAfGgZd/OrV2LcW Zqq4QDDwIz+Sku2Qqr2bSfWcmb5BiyejXyd8uhGE09QEWkj4h3vg6SsNsCpeI+081BSr 0gQMOX1M/dOmr4ruITGKikGaOhSBp/vmn3GunBiIdc0XFVLl9el+fBaumTZDj6xK0aUW O6oS4wWTYh0wAKDXzJZ1nlihKyna0hATVuN9obcw8pSFnMEFZ4mWzMpKZsooqKf0Btwk vpAuG95Xe+bXiYICKuNI0fuqQqlOmE4o97uzGAonJAcZQNLubnmcwoePAN/Sk1FnqhrC SMvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709234795; x=1709839595; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gqpC0LLsZAmk4obVOmg1LEqeGNecCiDiiC5C0BIjtcY=; b=sZJFf+ttlN+DqZXp6qddTpEt/O831CARmUg7DB8Iq1/yqQuXf8wKzoH+3E4tDoFSVR LmhTtUak5qOUS8E8Iov+/eACJqdpQgHAeTRUU4o+BW76jiQmx+Bmvidz5b95hApsZixH dwrHXvAYIZDRf/VVxRx2KCMEZFhxgGIJzMVMwG15ph1J73nvbJW9I+D34lhuQs9TETD7 qK1YE6oNOWe6hDaZ/QDSk9M7lZOyBxoSkuEJtyFpnK4tEAAestGQ/Y0dqfQfnxk6gfTZ J1P7LlarQWgboVFVqNjvEWqvxaXbYJg0C9NGScv1rxLmzZRlU3Blov9+NgexKw0qP8w8 36+Q== X-Gm-Message-State: AOJu0YyxH7r1zIxiL562MTN+vTktS/hhpwJuTjDu/CpgiRgVk13cRd22 yZOrb80MZY35Bm/Gdw81k8XhyhExlN44PK9+wmKbM+M0LYcltNbIZ4AJYp9+OTy3ch+l5DAobhm 4GOEORXKZA7khZpqHp/ygPG4wtLbDph6jGpNPKA== X-Google-Smtp-Source: AGHT+IGNoI8OC1SkNwwefjj0BDRXDo6TLRM+48Mnm7sj/SqFrLORAVd0OEJwFGcEJeDtWwx/IHitZT9eu8r6GH5/Onw= X-Received: by 2002:a17:907:1114:b0:a44:3056:1ec1 with SMTP id qu20-20020a170907111400b00a4430561ec1mr2212355ejb.6.1709234794550; Thu, 29 Feb 2024 11:26:34 -0800 (PST) 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 References: <435edf7c-a956-4317-b327-3372de70dbef@FreeBSD.org> In-Reply-To: <435edf7c-a956-4317-b327-3372de70dbef@FreeBSD.org> From: Xin LI Date: Thu, 29 Feb 2024 11:26:23 -0800 Message-ID: Subject: Re: Proposed ports deprecation and removal policy To: Florian Smeets Cc: ports@freebsd.org Content-Type: multipart/alternative; boundary="000000000000c45a1f06128a3c1b" X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from]; MLMMJ_DEST(0.00)[ports@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[delphij]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4Tm1Rx6s1Rz4YYt --000000000000c45a1f06128a3c1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 28, 2024 at 11:22=E2=80=AFAM Florian Smeets w= rote: > 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 me= t: > > - 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") > I have no objection with removing a port if upstream all died and nobody cared, but removing them "immediately" seems to be too harsh and not friendly for smaller software vendors. For example, bzip2 got their domain name stolen, but the project didn't really die and continued at sourceware.org. Please give the maintainer some time (e.g. by marking the port as DEPRECATED with a timeout time, maybe two weeks, maybe a month or even 3 months). > - Upstream WWW is unavailable: deprecate, remove after 3 months > Could you please explain why upstream WWW would warrant a removal? (I think removing the WWW=3D entry if the website is compromised or is no long= er available is perfectly fine, but why remove the port itself?) > - BROKEN for more than 6 months > I think if a port won't build on any of the official FreeBSD.org package cluster, the port is marked BROKEN with a deprecation period of 6 months (personally I think it's too long, 3 months should be the maximum). This should include ports that are IGNORED for all supported platforms and conditionally broken with all supported defaults: they should have correct dependency and are able to build in at least one poudriere environment. > - has known vulnerabilities that weren=E2=80=99t addressed in the ports t= ree for > more than 3 months > I think this is somewhat too vague. Known to whom? Registered at cve.mitre.org? In vuxml? Probably something like: if vuxml thinks the port is vulnerable, then it's marked FORBIDDEN immediately with a 3 month timeout (personally I think 2 weeks would be the maximum) by some automated script, and after the set time of being FORBIDDEN, the port is eligible for immediate removal. > 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=E2=80=99t seen a release in a long time > - Upstream looks inactive for a long time > IMHO, a lot of "friction" comes from lack of communication and not port getting removed themselves. For example, one of my port gets marked as DEPRECATED because a dependency was deprecated and scheduled for removal after 1 month, without any email telling me so (the port doesn't have a lot of releases and there isn't any release during that "parole" month), and it gets removed after that. So in order to know there is an ongoing deprecation of the port, I as a port maintainer would have to either watch the directory for any changes, or read all ports-git commit messages or at least a filtered version of it, and that's burdensome and inefficient use of developer time at best. What I would love to see happen is that, when a port gets marked as DEPRECATED, there is an automated system that sends me notification with something like: ACTION REQUESTED: X new ports you maintain is marked as DEPRECATED or, if it's just one port: ACTION REQUESTED: category/port is marked as DEPRECATED and will be removed on 1 month =3D=3D=3D=3D Hello, This is a friendly notification from FreeBSD port deprecation bot. In the latest scan the following ports you maintain are marked as DEPRECATED: Port name | Removal date category/port | 2024-03-30 ... and that email gets sent every 7 days until the port is removed or the issue is fixed. Or a bug is created and assigned to the maintainer, etc. Cheers, --000000000000c45a1f06128a3c1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 28, 2024 at 11:22=E2=80= =AFAM Florian Smeets <flo@freebsd.org= > 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.

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")

I have no o= bjection with removing a port if upstream all died and nobody cared, but re= moving them "immediately" seems to be too harsh and not friendly = for smaller software vendors.=C2=A0 For example, bzip2 got their domain nam= e stolen, but the project didn't really die and continued at sourceware.org.=C2=A0 Please give the maintaine= r some time (e.g. by marking the port as DEPRECATED with a timeout time, ma= ybe two weeks, maybe a month or even 3 months).
=C2=A0
- Upstream WWW is unavailable: deprecate, remove after 3 months

Could you please explain why upstream WWW would warran= t a removal?=C2=A0 (I think removing the WWW=3D entry if the website is com= promised or is no longer available is perfectly fine, but why remove the po= rt itself?)
=C2=A0
- BROKEN for more than 6 months

I think if = a port won't build on any of the official FreeBSD.org package=C2=A0clus= ter, the port is marked BROKEN with a deprecation period of 6 months (perso= nally I think it's too long, 3 months should be the maximum).
This should include ports that are IGNORED for all supported platforms = and conditionally broken with all supported defaults: they should have corr= ect dependency and are able to build in at least one poudriere environment.=
=C2=A0
- has known vulnerabilities that weren=E2=80=99t addressed in the ports tre= e for
more than 3 months

I think this is somewhat= too vague.=C2=A0 Known to whom?=C2=A0 Registered=C2=A0at cve.mitre.org?=C2=A0 In vuxml?

Probably somethin= g like: if vuxml thinks the port is vulnerable, then it's marked FORBID= DEN immediately with a 3 month timeout (personally I think 2 weeks would be= the maximum) by some automated script, and after the set time of being FOR= BIDDEN, the port is eligible for immediate removal.
=C2=A0<= /div>
A port can be deprec= ated 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=E2=80=99t seen a release in a long time
- Upstream looks inactive for a long time

IMHO, = a lot of "friction" comes from lack of communication and not port= getting removed themselves.

For example, one of my port gets marke= d as DEPRECATED because a dependency was deprecated and scheduled for remov= al after 1 month, without any email telling me so (the port doesn't hav= e a lot of releases and there isn't any release during that "parol= e" month), and it gets removed after that.=C2=A0 So in order to know t= here is an ongoing deprecation of the port, I as a port maintainer would ha= ve to either watch the directory for any changes, or read all ports-git com= mit messages or at least a filtered version of it, and that's burdensom= e and inefficient use of developer time at best.

What I would love t= o see happen is that, when a port gets marked as DEPRECATED, there is an au= tomated system that sends me notification with something like:

<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace">ACTIO= N REQUESTED: X new ports you maintain is marked as DEPRECATED

or, if= it's just one port:

ACTION REQUESTED: category/port is marked a= s DEPRECATED and will be removed on 1 month
=3D=3D=3D=3D
Hello,

= This is a friendly notification from FreeBSD port deprecation bot.=C2=A0 In= the latest scan the following ports you maintain are marked as DEPRECATED:=

Port name=C2=A0 =C2=A0 =C2=A0| Removal date
category/port | 2024-0= 3-30
...

and that email gets sent every 7 days until the port is re= moved or the issue is fixed.=C2=A0 Or a bug is created and assigned to the = maintainer, etc.

Cheers,
--000000000000c45a1f06128a3c1b--