Re: unmaintained packages hidden by team maintenance (was Re: Bits from the DPL)

Colin Watson <[email protected]> Thu, 5 Feb 2026 15:44:12 +0000
Newsgroups gmane.linux.debian.devel.project
Message-ID <[email protected]>
On Thu, Feb 05, 2026 at 04:14:15PM +0100, Simon Josefsson wrote:
>But why would that matter?  Presumably if there are serious problems
>with a team-maintained-but-really-one-person-doing-the-work-package,
>when that person goes missing, anyone else from the team can step in and
>fix it?  And if nobody else from the team takes responsibility, it is a
>team-wide problem that MIA probably cannot resolve.
>
>Or are you thinking of finding out which maintainers just stopped
>working and the packages doesn't have any serious problem, but several
>versions behind?  In well-working teams, I would think that someone else
>would just step in and feel at liberty of updating the package at some
>point.  This approach works well in the Go team, in my perception.

We have a lot of such cases in the Python team.  I think generally 
speaking we function reasonably well as a team, but there's a huge pile 
of stuff to do and only so many hours in the day.  I do quite often find 
that the alleged Uploader is somebody who last touched the package in 
2016 or something like that.  Updating the package once we notice this 
isn't normally a huge problem, but it does mean that things will 
probably have been lagging behind for some time until somebody notices.

>Perhaps a tool that finds a top-list of the "worst" version laggers in
>Debian would improve this?  That is, sort the set of packages which has
>been behind upstream's latest release for the longest time.

I wouldn't be 100% confident that something like this doesn't exist 
somewhere - sufficiently clever filters in UDD, say - but if it does 
then I've missed it and I would find it helpful.