On Friday, February 02, 2018 06:44:36 PM Adrian Bunk wrote: > On Fri, Feb 02, 2018 at 02:29:49AM +0000, Colin Watson wrote: > > On Fri, Feb 02, 2018 at 12:00:58AM +0100, Wouter Verhelst wrote: > > > Currently, RM bugs are filed against ftp.debian.org. > > > > > > It might make sense to have them filed against ftp.debian.org *and* the > > > package to be removed, instead. That way, people who care about the > > > package are more likely to see that it is about to be removed, and can > > > take corrective action if they don't want to have that happen? > > > > It'd probably make sense to use > > https://www.debian.org/Bugs/server-control#affects for this. > > How would that help? > > 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.
I think we are going to modify the pending removals page to indicate which requests are recent or have recent activity on the bug. I think that will put at least a little cushion in. As the FTP team member processing most of the rm bugs recently, what I mostly want is to have to touch the bug once. Once there's a visual indication it should be left to ripen for now, I'll be glad to do that. > 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. If in the maintainer's opinion it's better to remove the package than to leave it in the archive unmaintained, I think this is generally appropriate (see my previous mentions about not thinking FTP team should second guess maintainers). The one exception is if a non-maintainer objects to a removal and the objection includes them saying they will take over maintenance. Of course that almost never happens. Scott K
