On Sat, Feb 03, 2018 at 05:57:26PM +0000, Colin Watson wrote: > On Fri, Feb 02, 2018 at 06:44:36PM +0200, Adrian Bunk wrote: > > On Fri, Feb 02, 2018 at 02:29:49AM +0000, Colin Watson wrote: > > > It'd probably make sense to use > > > https://www.debian.org/Bugs/server-control#affects for this. > > > > How would that help? > > It would at least make it possible to see the pending action that's > relevant to the package in its BTS view, even if you perhaps only see it > too late. Better than nothing. Many times I've looked at bugs on a > package that I'm trying to fix in passing, and not noticed that it had a > removal bug either pending or recently processed. If the BTS doesn't > have that metadata, it can't do anything useful with it.
The place that contains all such data (including RM bugs) for a package is tracker.debian.org. It also contains many other information that could be relevant for you in that case, for example it shows when the package is orphaned or when there is an open RFS request (that might already fix your problem). Duplicating tracker in the BTS doesn't sound like a good approach to me. > I think at the moment the "affects" field in a bug's metadata doesn't > cause the maintainer of the affected packages to be copied on mail to > the bug, but it could probably reasonably be changed to do so, > eliminating the occasional problem where one of a package's maintainers > doesn't even realise that the RM bug was filed because they weren't > copied on it; again, only if the BTS has that metadata. If someone file an RM bug against a package without the consent of the maintainer and without Cc'ing the maintainer when submitting the RM bug, then the problem is the person who submitted the RM bug. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed