Hi Bastian, I'd just want to chime in and confirm what David wrote aleady. When we wrote the ITS procedure during Debconf Tawain, it was an explicitly designed that way, that it must not be a way to fast-orphan packages, bypassing the processes we have for that. This was intentional engineered that way, e.g to balance the procedure and the maintainers expectations, e.g to increase the acceptance of the "new procecure" in the project.
IF you are interested in the Some of the thought and rationales, I encourage you to read the announcment back then [1] [1] https://lists.debian.org/debian-devel/2018/07/msg00453.html On Thu, Sep 28, 2023 at 05:22:20PM +0200, Bastian Germann wrote: > Okay. What do you suggest for "team maintained" packages where there is no > active team member? > File MIA processes for each of the uploaders? Yes, involve the MIA team. > And then? The MIA team's bugs are not RC bugs, > so you cannot even NMU them based on the MIA bug. > I think, just letting such packages rot for one or two decades does not help > anybody, certainly not our users. Orphaning will not magically cure bit-rot or fix the unmaintained package problem. As written somewhere else in this thread, NMU needs to fix bugs, but if something is bit-rotted, there should be reported bugs, the bugs need *not* to be RC and even wishlist bugs can be (and I have done this) in the the scope of an NMU, especially if they are reported since a while. -- tobi (as MIA team member and author of the ITS process)
signature.asc
Description: PGP signature
