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
