Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Scott Kitterman <debian@kitterman.com>]

On February 1, 2018 1:47:17 PM UTC, Marvin Renich <mrvn@renich.org> wrote:
>* 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.

While I agree that would be best, I don't think it's the primary purpose of an rm bug.  It doesn't take an FTP team member to ping the maintainer to ask why, cc the bug.

If this concerns people, they can ask for more information.

Scott K