On Fri, Feb 02, 2018 at 06:44:36PM +0200, Adrian Bunk wrote: > Example: > > Subject: RM: hello -- RoM; obsolete > Control: affects -1 src:hello > > For the few days or hours between the RM bug being filed and the > package actually being removed, this would show up at > https://bugs.debian.org/src:hello > > The chances of someone looking at this specific BTS page during the > short amount of time between it showing up there and the actual > removal are close to zero.
> BTW: And then the next problem would be that the ftp team tends > to ignore non-maintainer objections in RM bugs and removes > the package anyway. As the FTP team is the single most important one in Debian, and also quite overworked, I'd refrain from anything that makes their workflow more tedious. If they have to read every bug over and over to check if it's good to be acted on, it'd waste a lot of their time. Thus, it's good to keep RMs as something that can be acted on immediately. That's why I proposed to have the burden of that "unripe RM" state carried by wnpp. There are other good proposals, like an usertagged bug on the package itself -- all that matters is a way to query these in bulk, to get a list you can automatically compare to what you have on your system[s], etc. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration ⣾⠁⢰⠒⠀⣿⡁ camps is back. What about KL Warschau (operating until 1956)? ⢿⡄⠘⠷⠚⠋⠀ Zgoda? Łambinowice? Most ex-German KLs? If those were "soviet ⠈⠳⣄⠀⠀⠀⠀ puppets", Bereza Kartuska? Sikorski's camps in UK (thanks Brits!)?
