Hello! Andreas Enge <[email protected]> skribis:
> Am Wed, Mar 11, 2026 at 10:17:01PM +0100 schrieb civodul: >> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ >> In 006-package-deprecation.md: >> +So altogether, this leaves (at least) two weeks between filing a removal >> +issue and the actual removal, which leaves enough time to channel >> +administrators to react accordingly. >> >> This looks like a short time frame to me. It's probably common for people to >> upgrade once per month at best, or once every few months. If I read >> correctly, >> that leaves enough time for a package to break and be removed entirely. > > Personally, I would like to shorten the procedure as much as possible, > to have a short as possible time where things are broken. (But this is > my perspective of someone removing things.) Others may prefer to keep > things for longer. So I have used a total time of two weeks where things > are broken and thus very disturbing for packagers, and a total time of > four weeks in less annoying cases as a compromise. > > This is certainly an important point to discuss, and something where > consensus must be reached. I could live with anything that does not > lengthen the current delays, that is, keeps it possible to remove > packages within one month. Yeah, I would tend to keep it at one month, in the hope it gives more time for people to notice and propose a fix (which I think is less likely to happen once the package has already been removed, though I don’t have any stats!). But then I agree we must also make it easy for the “package janitors” to easily navigate the list of pending removals. Did you find that setting a target date in Codeberg issues helps with this? Thanks for the reply! Ludo’.
