Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)
* Mattia Rizzolo <mattia@debian.org> [180201 03:26]:
> I seriously doubt ITRs or somesuch would help, you wouldn't notice them
> anyway.
> If you can parse a list of ITRs you can equally easy parse a list of
> packages with open RC bugs with next to the same effect.
I disagree. As a user, if I see RC bugs on a package, I have no idea
what work is or isn't being done by the maintainer or others to address
those bugs. However, if the maintainer (or someone close to the
package) files an ITR, I now know that this is my last chance to speak
up. With something similar to apt-listchanges that notifies me when I
do aptitude update that a package I have installed will be removed soon,
I have an opportunity to react. Something similar for RC bugs would not
serve the same purpose (though it might be very useful for someone
looking for ways to contribute to Debian: "There are RC bugs on these
packages that you use; would you like to help out?").
> RoQA packages without RC bugs is very rare (and I don't like them
> myself), and ROM shouldn't be second guessed anyway (as an ftpteam
> member stated).
I agree that the FTP team should not second guess the maintainer's
removal request. However, with or without a new ITR process, I think it
would be justified (and good practice) for the FTP team to start
requiring the maintainer to record in the bug the reasoning behind the
removal. This appears to be common, but not universal, practice when
filing ROMs, but making it mandatory and enforced by the FTP team does
not seem out of line. This has nothing to do with second guessing; it
is about openness to the rest of the Debian community (esp users who are
wondering why their favorite niche package didn't make it into the next
release). And as stated elsewhere in this thread, it will help a
prospective new maintainer know whether reintroducing the package will
be worth the effort.
...Marvin
Reply to: