Date: Wed, 28 Feb 2024 16:47:54 -0700 From: "Edward Sanford Sutton, III" <mirror176@hotmail.com> To: ports@freebsd.org Subject: Re: Proposed ports deprecation and removal policy Message-ID: <CO1PR11MB4770AC3B189467872EDB17C1E6582@CO1PR11MB4770.namprd11.prod.outlook.com> In-Reply-To: <7d2a8e8e671578f99ed05431b68cf015@bsdforge.com> References: <435edf7c-a956-4317-b327-3372de70dbef@FreeBSD.org> <fb42e7b5-be11-4d6f-bacd-90bfd361ed48@quip.cz> <1500d4f4-2bdb-4d3b-8848-900346f4d194@FreeBSD.org> <7d2a8e8e671578f99ed05431b68cf015@bsdforge.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/28/24 14:38, Chris wrote: > On 2024-02-28 12:13, Florian Smeets wrote: >> On 28.02.24 21:00, Miroslav Lachman wrote: >>> On 28/02/2024 20:22, Florian Smeets wrote: >>> >>>> 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 miss some sort of time frame like in the following cases. The way >>> the sentence is written now, it looks like there may be an immediate >>> removal on the first day of the outage. >>> >> >> Good point. Yeah, it certainly isn't the intention to remove it >> immediately. I >> will make a note to add a time frame. I'm thinking 4 weeks, as that >> feels long for >> a site to go away and reappear, but we might just make it 3 months as >> with most of >> the other points. > I'd vote for 3 (mos). But 2 also seems reasonable. So that those that > use it. But don't > update frequently get a chance to notice, and subsequently save/maintain > it. :) In general, a port could always be pulled back out of a death that happens too early as the ports tree history is always available. The 'saving' makes sense both for a webpage (especially if valid WWW is 'required', which seems debatable and unlikely). A different take on 'saving' a (port, is availability can be interrupted; I build my own packages with poudriere+latest but a quarterly package user may be hit with it disappearing unexpectedly depending on when it gets marked, if that mark is applied to their quarterly branch (committers are human so if its not automated, it will likely happen at some point), when the next quarterly/latest build finishes so that package users see it through message or package deletion. Then if it wasn't already deleted yet, pkg users for sure find out when it is and removed. Once that point is reached, users then have to wait for the port to be restored to the appropriate branch and the next build run to rebuild it; conditionally, users of quarterly branches are the ones to have the least time/chance to react and likely the most time to wait for a resolution when undone/resolved. Do 'scheduled' announcement and action times ever correspond (close) to or account for when builds complete on pkg repositories and when next quarterly update sequence occurs instead of when a Makefile is altered? If the intent is to inform users with a timeframe before action occurs then it is important to make sure the last event that could delay that information going out is considered for scheduling purposes; maybe an automated (or documented committer checklist) check should be implemented that confirms the date it hit the last relevant repository branch/mirror before the next step is performed. Remember that pkg users don't see "broken" unless dependencies were updated without it which causes removal instead of a message; only fix I see here would be like MOVED file but for scheduled/upcoming changes to be announced from. That would also require it be presented before or during delete or tracking non-automatic packages being removed without a deliberate `pkg delete` so it can be prompted from information introduced later. >> Thanks >> Florian >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CO1PR11MB4770AC3B189467872EDB17C1E6582>